PrestaShop store audit: the complete checklist
A PrestaShop audit is not just about security: it means reviewing versions, modules, errors, performance, technical SEO, checkout, email, backups and legal texts. Here is a table with what to look at, how to check it and which warning sign should worry you.
An audit of a PrestaShop store reviews, in order, versions and modules, logged errors, performance, technical SEO, checkout, email, backups and legal texts. The goal is a prioritised list of what needs fixing, with evidence for each problem, not a generic report.
Audits are usually commissioned when something goes wrong: sales drop, traffic falls, the store is slow or you are about to change provider. It is better to do them beforehand. This checklist covers the whole store; security has its own article on the blog, with more detail on employees, files and access.
1. Versions: the starting point
- PrestaShop version and whether its branch still receives patches.
- PHP version and its end of support.
- Theme: whether it is a purchased theme, a custom one or a child theme, and whether the original has been modified (which prevents updating it).
- Modules with their installed version against the latest one published by the author.
A store on an unsupported branch does not need a detailed audit first: it needs an update plan, and the rest of the findings are organised around it.
2. Orphaned modules and overrides
Over the years, modules nobody uses pile up: installed for a campaign, replaced by others, or uninstalled but with their folder still on the disk. Each one is code that runs or could run. Check:
- Installed but disabled modules that will not be used again.
- Folders in
modules/that do not correspond to any installed module. - The
override/folder: which core classes or controllers are being replaced and which module put them there. Overrides are the most common reason an update breaks the store. - Modules that do the same thing (two search engines, two cookie modules, several SEO ones).
3. Errors in the logs
Errors are not visible in the store until they affect a sale. Look at the server's PHP log, the PrestaShop logs (in var/logs in modern versions) and the back office log under Advanced Parameters. Look for recurring errors, fatal errors, exhausted memory and 500 responses. An error that appears a thousand times a day is almost never harmless.
4. Performance
- Server response time on the home page, a large category, a product page and the checkout.
- Mobile experience metrics (loading of the main content, interactivity, layout shifts).
- Image weight and whether images are served in modern formats and at the right size.
- Amount of JavaScript and CSS that modules load on every page, including those where it is not used.
- OPcache, PrestaShop cache and debug mode switched off in production.
5. Indexing and technical SEO
This is where most silent problems appear, because the store works and nobody notices:
- Two
h1on the same page, or none: common in themes that put the logo or the store name in anh1. - Empty or duplicate meta titles and descriptions on products, categories and brands.
- Canonicals pointing to the wrong URL, or filtered and paginated pages indexed without control.
- Sitemap that is kept up to date and only includes URLs that return 200.
- 404 errors from discontinued products without a redirect, and redirect chains.
- Languages: correct alternate language tags and translated URLs.
- Product structured data (price, availability) without errors.
6. Checkout, email and backups
- Checkout: a test order with each payment method and each carrier, on mobile and desktop, as a guest and with an account.
- Email: that the order confirmation, the status change and the password recovery arrive, and that they do not go to spam.
- Backups: when the last one was made, what it includes, where it is and when a restore was last tested.
7. Legal
Legal notice, terms of sale, privacy policy, cookie policy with a banner that really blocks what is not necessary, information on the right of withdrawal and a checkbox to accept the terms at checkout. Having the texts is not enough: they must be linked in the right places and match what the store actually does.
8. Data and back office
The part that gets looked at least and wastes the most time every day:
- Tables that grow unchecked: abandoned carts from years ago, connection statistics, logs and saved searches. They slow down backups and the back office.
- Inactive products and categories that remain in the catalogue without anyone deciding what to do with them.
- Employees and profiles: who has access, with which permissions, and whether there are accounts of people who no longer work with you.
- Scheduled tasks: which ones exist, whether they run and what happens when they fail.
- Integrations with ERPs, marketplaces or carriers: whether they sync and who finds out when they stop.
What the result should look like
A useful audit ends in a short document, not fifty pages of screenshots. For each finding: what was found, where, the evidence (a log entry, a URL, a screenshot), its impact and how much it costs to fix. With that you can decide what gets done this month, what gets planned and what is left. Also keep the inventory that comes out of the audit (versions, modules, overrides, scheduled tasks): it is the basis for the next review and for any new technician who joins.
The printable table
| What to check | How | Warning sign |
|---|---|---|
| PrestaShop and PHP version | Back office, Advanced Parameters, Information | Branch without patches or unsupported PHP |
| Modules | Module Manager and modules/ folder | Folders without an installed module, modules not updated in years |
| Overrides | override/ folder | Core classes replaced without knowing by whom |
| Errors | PHP and PrestaShop logs | Fatal errors or errors repeated daily |
| Performance | Response times and mobile metrics | Slow back office, server response over one second |
| Technical SEO | Store crawl and Search Console | Two h1, empty metas, wrong canonicals, 404s |
| Checkout | Test order for each payment method | Payments that do not become orders, JavaScript errors |
| Test order and message headers | Emails that do not arrive, or no SPF and DKIM | |
| Backups | Restore one in a separate environment | Nobody knows when the last one was made |
| Legal | Review texts, banner and checkout | Banner that does not block, no terms checkbox |
How to solve it in PrestaShop
An audit is only useful if someone applies what it finds. At Rekire, the technical SEO for PrestaShop with AI service is a monthly subscription with no lock-in in which we apply the improvements directly in your store's code: catalogue and metadata optimisation with artificial intelligence, plus speed and usability improvements. For the technical side (versions, orphaned modules, overrides, errors, checkout and backups) we work with bundles of PrestaShop support hours, with an estimate before we start and a breakdown of each task. Reviewing the store once a year is cheaper than discovering its problems once they have already cost you sales.
Frequently asked questions
How often should a PrestaShop store be audited?
A full review once a year, and always before a migration, a change of provider or a major campaign. Whatever can be automated (errors, security, expiry dates) is best monitored continuously.
What is the difference between an SEO audit and a technical audit?
The SEO audit looks at how search engines see the store; the technical one, at how it is built and whether it is secure and stable. They overlap on performance and indexing, and the useful approach is to do them together.
Can I do the audit myself?
A good part of the checklist, yes: versions, test orders, email, legal texts and empty metas. Overrides, error logs and suspicious folders need someone who knows PrestaShop.