Write Product Titles, Descriptions and Metadata in PrestaShop

What we would do

We would identify what stops a buyer choosing before rewriting the catalogue: unclear names, missing fit information, weak search summaries or incorrect output. The right route depends on your existing shop: its PrestaShop form, theme, SEO modules, supplier or ERP integrations, product data, languages, markets and the team maintaining them. Check which system owns each field before editing it.

For a bulk import, template change or URL change, use a staging copy with the same theme and modules, isolated from live customer emails and outbound integrations. Rehearse a representative batch, keep the original values and test restoring them. Agree the approved fields, publication window and person checking the live result. A small manual copy correction can use the existing editor once you have retained the original text and checked the rendered page.

Choose the change that matches the problem

If you want help deciding which pages and causes to tackle, the PrestaShop SEO Audit & Action Plan provides a ranked diagnosis and fixes; implementation and content writing are outside its scope.

Understand the product fields and their fallbacks

Open Catalog > Products and edit a product. In the modern PrestaShop 9 form, Name appears in the header, Summary and Description are in the Description section, and metadata and Friendly URL are in SEO. Legacy forms use different tabs, including Basic settings or Information.

Product language data is scoped by language and shop. In native PrestaShop 1.7.8 and 9, an empty product meta title falls back to the product name. An empty product meta description falls back to Summary with HTML tags removed. The fields remain separate in storage. Theme and module output can modify the final page, so check its HTML.

The product Name limit is 128 characters in those releases. That is different from a theme's card truncation and from Google's variable search-result display. The modern PrestaShop 9 Summary has a configurable limit, with 800 characters as the default. Review Shop Parameters > Product Settings > Max size of product summary before drafting longer text.

Write a summary and description that answer buying questions

Start with the product's main use and the detail that distinguishes it. Keep the summary useful on its own. Put depth in the full description rather than pasting the same text into both fields.

1. Summary: explain what the product helps the buyer do, who it suits and its decisive specification.
2. Features and benefits: connect a factual attribute to a practical consequence without inventing durability, performance or installation claims.
3. Fit and use: explain dimensions, compatible parts, installation requirements, care and limitations.
4. Specifications: present the exact values and included parts in a scannable table or native Features.
5. Next steps: link to a relevant category, accessory or buying guide where it helps the purchase.

For a linear shower drain, useful questions include its length, outlet size, installation height, grate type, waterproofing interface, cleaning access and included parts. “304 stainless steel” can describe material, but it does not justify “rust-proof for a decade”. A flow-rate claim needs the relevant tested conditions. Avoid universal fit or installation-time promises unless they apply to the actual item.

Use the native Features system for reusable attributes that need consistent filtering. For a one-off specification block, switch the description editor to its HTML source view and insert a plain table with header cells. Save it and test the rendered table on a narrow screen; Bootstrap classes are not guaranteed across themes. Downloads, size charts and installation PDFs can have dedicated attachment or tab surfaces when your setup supports them. For reusable guides, Product Extra Info Tabs manages shared content with local product exceptions. Check that any essential fit warning remains visible where your theme places the buying controls.

Write as much as the buying decision requires. A simple shirt and a configurable technical fitting need different depth. Use short paragraphs, useful subheadings and real lists. Describe finish or feel accurately, and answer recurring questions about fit, delivery contents and care. Keep live stock counts and promotion deadlines in systems that update them rather than hard-coding numbers into prose.

Manufacturer text can be a factual starting point. Add useful product-specific information and check that you may reuse it. Repeated text within one page is not the same as duplicate URLs and does not double an SEO penalty. Duplicate content is not automatically a spam-policy violation or a guarantee of ranking failure. Google's SEO Starter Guide explains the distinction and canonical handling.

Use the terms customers use where they fit naturally. A drain description might mention “60 cm linear shower drain”, “walk-in shower drainage” or “tile insert” only when accurate. There is no required number of repetitions or keyword density that makes a product rank. Do not promise that a specific phrase is always higher intent.

Work through a complete product rewrite

Suppose the product sheet confirms a 304 stainless steel drain, 60 cm length, a 50 mm outlet, a rated flow of 48 L/min and a kit containing the drain body, tile insert frame and hair trap. These are example inputs, not specifications for every drain. Retain the supplier's applicable installation and flow-test conditions alongside the values.

Before: Name: “Premium Drain”. Summary and Description: “Best quality, fits every shower and drains fast”. Metadata is blank. This gives the buyer no dimensions or kit contents, and makes compatibility and performance promises the supplied facts do not support.

Before publishing, complete any missing installation conditions, cleaning instructions and waterproofing details from the actual product documents. The 50 mm outlet does not justify “fits any 50 mm waste”, and the rated flow does not promise that every shower will drain without pooling.

Write names that stay clear on cards and order lines

A practical naming pattern is product type, useful differentiator, then a standalone variant. For example:

• Linear Shower Drain, Stainless Steel 304, 60 cm
• Wall-Mounted Bathroom Cabinet, Oak, 60 cm
• Over-Ear Bluetooth Headphones, Noise Cancelling, Black

Use these patterns only with attributes that apply to the item. Put the distinguishing words early enough to survive your theme's card clamp. Check a group of similar products on mobile: can you tell the 60 cm and 80 cm versions apart without opening each page?

The visible Name can stay concise while Meta title adds a useful detail, as in the worked example. The latter remains a preference, not a command to Google.

When size or colour is a real combination, the base Name is shared and selected attributes appear separately in relevant theme, cart and order contexts. Avoid a fixed “Blue, Large” in the base name when the customer can choose other combinations. For separate products, a size in the Name can be useful.

Leave out unsupported superlatives, repeated synonyms and stale marketing dates. Use the Reference field for internal SKUs. Retain a model number in the Name when customers use it to identify the product, such as a replacement part. Keep separators, units and capitalisation consistent within a product family.

Renaming affects current storefront text and future order snapshots. Existing order details store product_name, including the selected attributes at creation, so a rename does not rewrite old invoice lines.

Keep merchant-feed titles separate too

The same example product can keep “Linear Shower Drain, 60 cm” on the storefront while a Merchant Center title includes “Linear Shower Drain 60 cm, Stainless Steel 304, Tile Insert” when those attributes are confirmed. A feed title is neither the product Name nor the HTML title: inspect which fields your connector actually exports, including combination attributes. Do not lengthen the storefront Name just to satisfy a feed mapping that can be changed separately.

Keep the saved Friendly URL independent of this copy decision and review the product feed guide for the export setup. Check the generated feed before sending it, because some integrations derive their titles directly from Name.

Keep renames and URL changes under control

Name and Friendly URL are separate fields. Friendly URLs can be generated from names, but regeneration depends on your settings and editing workflow. Check both values when changing a live product.

PrestaShop 9's default product route omits the category while retaining the product ID. Removing the category from that route does not create a new dependency between Name and slug. Under Shop Parameters > Traffic & SEO, review the actual product route in Schema of URLs; there is no universal native “Add a category in the URL” switch.

An old slug on an ID-based route can still resolve the product. Core canonical redirection can send it to the current URL, depending on configuration. Custom routes and URL modules can behave differently. Before a bulk rename, preserve the old slug where appropriate or test the old URL's status and permanent redirect to the intended destination. Avoid redirect chains and update internal links.

Use the URL and redirect guide when you need a wider route migration.

Write titles and descriptions without snippet promises

Inspect the rendered <title> before adding your store name. Core metadata completion does not universally append a brand suffix. Your theme or modules may add one, and Google can generate its own title link. Add concise branding once where useful rather than assuming a global suffix setting exists.

Use a title that describes the page: a product and its differentiator, a category and its useful scope, or a guide topic and its practical purpose. “Waterproof Hiking Backpack 40 L” tells a searcher more than an internal range name alone. Keep every claim consistent with the visible page. After applying a metadata template, compare distinct products for identical or boilerplate titles and add a confirmed detail that distinguishes each page.

About 40 to 60 characters can be a useful drafting target for a title, and 120 to 160 for a description. These are editorial guides, not Google character limits or display guarantees. Device width, text width, query and generated output matter. Native field validation limits are separate again. See Google's title-link guidance and snippet guidance.

Write a description that summarises this specific item or page and gives a real reason to open it. Use a material, size, fit detail or genuine service policy rather than “welcome to our great store”. Do not invent handmade origin, delivery guarantees or returns periods to make an example persuasive.

Google can choose a different snippet even when you supply a description, and a different title link even when the HTML title is valid. Its snippet is query-dependent and can use page text. A supplied description is not guaranteed to be a fallback that appears whenever Google does not rewrite it.

A meta description can help explain your page to a searcher, but Google does not use it as a direct ranking factor, as its metadata explanation states.

Google Search ignores the meta keywords tag. Keep that statement specific to Google rather than extending it to every search engine. Product prices, availability and review displays in search results involve structured data and eligibility, not the meta title or description alone. See structured data for PrestaShop.

Edit the correct page type

• Products: the product's SEO section.
• Categories: edit the category's SEO fields under Catalog > Categories.
• CMS pages: edit the page under Design > Pages.
• Home and supported controller metadata: the page metadata list under Shop Parameters > Traffic & SEO.

Do not assume all those page types share the product's summary fallback. Check each rendered page independently.

For a category that actually contains tile-insert drains, a title such as “Tile-Insert Shower Drains | Compare Sizes” serves a browsing decision. A description could say “Compare tile-insert shower drains by length, outlet and installation requirements. Open each product for its dimensions and included parts.” Check that the range and page content support those comparisons; do not reuse a single product's specifications as a category-wide promise.

Adapt the content for each language and shop

Write and review Name, Summary, Description, Meta title, Meta description and Friendly URL for every enabled language. Use the language selector and confirm the current shop context. A translated description can still omit an important size, reverse a compatibility condition or use the wrong technical term.

Research the terms your buyers actually use. For example, “shower drain”, “Duschrinne”, “caniveau de douche” and “canaletta doccia” can be useful starting points for different markets, but product type and local usage still matter. Machine translation can assist; its origin alone does not determine ranking. Review accuracy, usefulness and local terminology.

Check language URLs, links and alternate-language annotations alongside the content. Hreflang helps associate alternate versions; it does not guarantee a particular result or replace good translation. Use the international content guide for the wider setup.

Update a catalogue without overwriting protected content

The ordinary product editor changes individual records, but native import can update names and descriptions in bulk. Advanced Parameters > Import is an importer, not a full product-content export facility.

1. Obtain a complete export with product IDs, language, shop, names, both description fields, metadata and slugs through a suitable export tool, Webservice or targeted read-only SQL.
2. Keep an untouched backup and define which fields and products you intend to change.
3. Rewrite in a structured file with one consistent naming pattern and product-specific facts.
4. Map the native import's supported Name, Summary, Description and metadata fields. Match existing products by the intended IDs or supported reference workflow, and select the correct language.
5. Test a small batch on staging, including HTML, accents, quotes, combinations and empty fields.
6. Check that the import updates the intended products without creating duplicates or replacing protected values.
7. Apply the approved batch and inspect storefront, URLs, cart text and representative future orders.

A product-list CSV may omit the full content you need for rollback. Check that your backup can restore both descriptions before editing. Set the scope of any find-and-replace operation, preview the changes and keep a backup.

Include a protected top seller, a product with combinations, a translated product and deliberately blank fields in the staging sample. Compare the exported before and after values by product, language and shop. If an editor and a supplier or ERP import both write the same field, agree which owns it and test a synchronisation cycle before launch.

For the live batch, agree how concurrent staff edits will be captured so the import cannot silently replace newer copy. Run the approved import with the tested file and mapping, keep the change record and restore only the affected fields if rollback is needed. Rehearse that restore on staging; a whole-shop database restore can discard unrelated orders or edits.

Metadata templates can help large catalogues, but inspect their output and exceptions. Bulk operations can replace handwritten fields; do not assume existing top-seller metadata is automatically protected. Exclude protected products from the operation where supported, or choose an operation that preserves them, and export the original values first. Where catalogue scale warrants it, SEO Revolution brings Search Console evidence and shared catalogue rules into one workspace with individual exceptions; follow that help page for module-specific setup.

Check rendered output and measure the result

1. Open the product and representative listings on desktop and mobile. Check headings, card truncation, summary, specifications and links. If saved copy is absent, check whether the theme renders that field or a module supplies a replacement before rewriting it again.
2. Inspect the actual HTML title and meta description in every relevant language. Test blank-field fallbacks on staging if you rely on them. If old output remains, compare the saved value with the page source, then check the relevant cache and any metadata module rules.
3. Check the canonical URL and an old published URL after a rename.
4. Verify that all fit, performance, material and policy claims match the real product and offer.
5. Use Search Console to review queries, impressions, clicks, CTR and position for the page.

Record what changed and when. Give Google time to recrawl and collect enough observations for the comparison. There is no fixed two- or three-week interval that guarantees a useful sample.

Compare similar queries, devices, countries and positions, accounting for seasonality and changes in search appearance. Low CTR can reflect intent, competing results, price, position or a generated title; it does not identify a metadata defect by itself. Change one main variable at a time when practical, then review qualified visits and sales as well as clicks.

What to ask your developer or agency

• Which system writes each field, and will any scheduled import replace the agreed copy?
• Which products, languages and shops are included, and where is the list of protected exceptions?
• Can you show the original export, the proposed field changes and the tested import mapping?
• Which theme or module controls the visible Summary and the rendered metadata?
• Did the old published URLs, merchant-feed output and future order text pass the staging checks?
• Who approves technical claims and local terminology, and who can restore the affected fields after publication?

Ask for the checked product URLs, before and after values, outstanding exceptions and restore instructions. Your catalogue team needs a repeatable process for new products as well as a completed batch.

Questions owners ask

Which products should we improve first?

Prioritise products with recurring buying questions or preventable fit mistakes, alongside pages already receiving relevant search impressions. Use customer messages and return reasons to identify missing information. Traffic alone can miss a commercially important product with poor copy.

Can we use AI to write the first draft?

Give it approved product facts and a clear field structure. Require it to flag missing information rather than invent compatibility, certification or delivery promises. A person who knows the product must approve the result and check that details from a neighbouring variant have not been carried across.

Can English go live before the other languages?

Publish reviewed languages in planned batches if your workflow supports that scope. Keep the existing copy in languages still awaiting review and inspect the import's behaviour for omitted or blank language values on staging. Assign an owner to the remaining translations.

Do we need a PrestaShop upgrade for a copy rewrite?

The native editor already provides the core product content fields. Check your installed form and editing workflow before expanding the project; a copy rewrite alone is not a reason to upgrade. Assess any unsupported software or integration problem separately.