The problem
A PrestaShop store with five hundred products has five hundred meta titles, five hundred meta descriptions, five hundred short descriptions and as many long ones. In most of the catalogues I have seen, a good share of those fields is empty or filled in automatically by the theme with the product name. Categories and brands, which are the pages with the most traffic potential, often don't even have that.
The reason is always the same: writing them by hand is a cost in time and resources. So those pages stay online, collect impressions on Google and convert none of those impressions into clicks.
On the other hand, generating the copy in bulk with AI and uploading it makes things worse. It produces descriptions that are neither plausible nor correct: materials the product doesn't have, invented measurements, availability claimed without looking at the warehouse. On an e-commerce, copy that isn't credible and isn't true costs more than an empty field.
What the module does
It installs on PrestaShop and adds an entry under Catalog. From there you work on three types of entity from the same interface: products, categories and brands.
For each one it fills in four fields: meta title, meta description, short description and long description. The meta fields are on by default, the descriptions are enabled when you need them.
The dashboard filters the catalogue by category, brand, field status, presence of Search Console data and impression threshold, and sorts by impressions, clicks, CTR or position. It is there to decide where to start: there is no point in beginning with the products nobody searches for.
How it works
It starts from real searches. For each page the module reads from Google Search Console the queries that page already appears for, and ranks them by missed opportunity: many impressions, few clicks. Those queries say which words people actually use to look for that product, and they are the brief the copy is built on. You don't optimise for the keyword that looks right, but for the one the page is already losing traffic on.
It proposes, it doesn't write. Every suggestion goes through a review screen with a SERP preview, character counters and a panel explaining why that copy was written the way it was, which queries motivated it and where every descriptor used comes from, with the catalogue data that proves it. You approve, edit or discard. Fields already handled by hand are left alone.
It checks before letting you approve. An automatic validation layer flags blocking problems in red (a descriptor that doesn't exist in the product data, a wrong brand, availability claimed without stock to back it) and minor warnings in yellow, such as lengths out of range or superlatives. Copy flagged in red stays out of bulk approval.
You can go back. The previous value of the field is saved before every write. Rollback is possible at any time, even on a single field of a single product.
It measures. Every page written is compared with itself before and after the work, over symmetrical windows, with the option to compare against the same period the year before as well. It serves to separate the effect of the work from seasonality, which in many sectors explains a good share of the variation. The report can be exported to CSV.
You choose the model
The module isn't tied to one vendor. In the settings you choose between Claude (Anthropic) and Google Gemini, and within the provider you select the model: the most capable one where the quality of the copy matters, a cheaper one where volume weighs more. Credentials for both providers stay saved separately, so you switch from one to the other (or compare them on the same catalogue) without reconfiguring anything.
On the models that support it you can turn on web search: the AI checks the product online before writing about it and cites the sources it used. It helps on catalogues where the internal data is thin (a product code and little else) and the right descriptor sits in the manufacturer's spec sheet rather than in the database.
It is a metered feature: every search has a cost, so you turn it on where it actually helps and leave it off elsewhere. Every call is logged with tokens consumed, searches performed, sources cited and estimated cost. The spend is verifiable line by line, not at the end of the month.
In production at Angelini Arredamenti
Angelini Arredamenti is a Puglia-based furniture e-commerce on PrestaShop that I look after together with Studio Polvo. In 2025 we worked on tracking, Google Shopping and product pages: in nine months traffic nearly doubled.
The catalogue, though, was still uncovered on the content side. Between June and July 2026 I rewrote around three hundred product pages with this module, plus the category and brand pages, starting with the ones with the most impressions on Search Console. Every suggestion went through manual review before going live.
Security and status
The credentials for the AI providers and for the Google service account are encrypted with PrestaShop's own encryption system: never stored in the clear, never written to the logs. Queries are parameterised, AJAX actions are protected by anti-CSRF tokens, and the HTML of the descriptions is re-sanitised server side against a tag whitelist.
Installation creates its own tables without touching the native ones, and updates are additive: past suggestions, rollback backups and credentials survive from one version to the next.
The module is in production with one client. It is not distributed on Addons. If you are interested and need help with your e-commerce, get in touch.