FAQs on product and category pages: where to get them and how to mark them up

Reviews come after the purchase. Questions come before. If someone does not know whether the charger works with their model, whether the size runs large or whether the product can stand being outdoors, and the product page does not say, they will do one of three things: write to you and wait, look for it in another store, or leave. Well-written FAQs settle that doubt on the spot, and along the way for everyone who comes after with the same question.

Two kinds of questions, two places

On the product page

Questions about that specific item: compatibility, real dimensions, use, assembly, what is in the box, how to wash it, how it differs from the model next to it. Ideally they should be real customer questions, answered publicly by the store.

On the category or brand page

General questions that affect all its products: how to choose the size, what the certifications mean, what warranty that brand offers, how shipping works for bulky products. These are written by the store, editorially, and they also give the category useful content of its own, which is often what it lacks.

Mixing the two is a common mistake: repeating the same five generic questions about shipping and returns on every product page produces hundreds of pages with the same block of text, which add nothing new and make the page longer.

Where to get the questions

• Customer service email, phone and chat. The main source. Ask the team to note down the questions that recur per product or per family.
• Returns. “It wasn’t compatible”, “it’s smaller than I thought”. Every frequent return reason is a question the product page should answer.
• Reviews. Complaints and nuances in reviews point to what customers did not know before buying.
• The store’s internal search and Search Console queries containing “how”, “does it work”, “can you” or “difference”.
• Customers’ own questions on the product page, if you let them ask.

Avoid inventing questions to slip in keywords (“Where to buy the best cheap X?”). They are obvious, they do not help the customer and they give you nothing a good title would not.

Customer questions: always moderate

Letting customers ask on the product page works well, on two conditions:

1. Prior moderation. The question is written by a stranger on a page Google indexes. Without approval, you will get spam, links, the customer’s own personal data and complaints that should go through another channel.
2. A quick answer signed by the store. A question published without an answer looks abandoned. If you will not be able to reply within a reasonable time, better not to turn the feature on.

Some measures that reduce the workload: only allow customers with an account to ask, limit the number of questions per person per hour against bots, notify customers by email when their question has been answered and let others vote for the most useful ones.

How to write good answers

• Direct: the answer in the first sentence (“Yes, it is compatible with…”), the detail afterwards.
• Specific: dimensions, models, lead times. “It depends” on its own answers nothing.
• Consistent with the product page: if the answer reveals that a detail is missing from the description or the features, add it there too.
• Cautious about health, safety and results: if you cannot back it up, do not claim it.
• Reviewed over time: when the model, the supplier or the shipping policy changes, old answers can become false.

Structured data: what it does today

The schema.org FAQPage markup describes a list of questions with their answers. For years it let Google show question drop-downs under the result. Since 2023, Google only shows that rich result for authoritative government and health websites. A store will no longer get it, however it marks it up.

Is it still worth marking up, then? It makes sense if you do it properly and without expecting the drop-down:

• Other search engines and assistants read the markup to understand the content.
• It makes the page’s question-and-answer structure clear.
• It costs nothing if the module generates it from the real content.

What you should not do is mark up as FAQ text that is not visible on the page, or the same generic block on every product page. For customer questions with several answers there is another type, QAPage, intended for forums and single-question pages, which does not fit a product page with many questions.

And a technical detail: if the questions are loaded by JavaScript after the page, or only when the user clicks “see more”, make sure they are in the HTML. Hiding them with CSS behind a button is not a problem; not loading them is.

How many and where to place them

On the product page, between three and eight visible questions are usually enough; the rest behind a “see more”. Place them after the description and features, before the reviews. On the category page, below the product listing, so as not to push the products down on mobile.

One last recommendation: if you migrate from one questions module to another, or from an old version of PrestaShop to a current one, rescue the content. Years of answered questions are an asset that is easily lost in a change of theme or module.

How to solve it in PrestaShop

RKR Preguntas lets customers ask questions on the product page and the store answer them publicly, with a moderation queue (search, filters and bulk actions), the store’s signature, one-vote-per-person voting and three email notifications that can be enabled separately. By default only customers with an account can ask, with a cap per person per hour, and questions behind “see more” remain in the HTML. It also lets you write editorial FAQs attached to categories or brands with their FAQPage markup, which PrestaShop 9 does not output by default, and imports questions and FAQs from another module or from a CSV with a dry run first. When a customer’s data is deleted, it anonymises without losing the answer.