Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Loading...
A Magento website audit is a structured review of your store's code, performance, SEO, security, extensions and data, done before you commit budget to new development. The goal is simple: find the problems that would make new work slower, riskier or wasted. The 60 checks below are grouped into six areas, and each one tells you how to check it and what a fail typically costs you if you ignore it.
You can run many of these yourself with admin access and free tools. Others need a developer with server and code access. Either way, a written audit gives every agency or developer the same starting point and makes quotes comparable.
How to use this checklist
- Work on a staging copy where checks need code or database access. Never test destructive changes on production.
- Mark each check pass, fail or unknown. Unknowns are findings too: they mean nobody owns that area.
- Prioritize by "what a fail costs". Security and data fails come first, then anything blocking upgrades, then performance and SEO.
- Repeat it yearly, and before any major project such as an upgrade, redesign or replatform.
1. Code and platform (10 checks)
| # | Check | How to check | What a fail costs |
|---|---|---|---|
| 1 | Magento version is within standard or extended support | Run bin/magento --version; compare with Adobe's lifecycle policy | No security patches; compliance risk; forced emergency upgrade |
| 2 | Latest security patch for your line is applied | Compare version suffix (for example -p5) with Adobe's release notes | Known vulnerabilities stay open |
| 3 | PHP version is supported by your Magento release | php -v against Adobe's system requirements | Unpatched runtime; blocks the next upgrade |
| 4 | No edits to core files under vendor/ | Compare vendor/ with a clean Composer install, or check for patches applied outside Composer | Changes lost on update; hidden behavior |
| 5 | Custom modules use plugins and observers, not broad class preferences | Search di.xml files for preference elements on core classes | Conflicts with extensions; higher upgrade effort |
| 6 | Code passes the Magento Coding Standard | Run PHP_CodeSniffer with the Magento2 ruleset on app/code | Slower reviews; more defects per change |
| 7 | Code is in version control with a clear deployment process | Ask for the repository and deployment steps | Risky releases; no rollback |
| 8 | Store runs in production mode | bin/magento deploy:mode:show | Slower pages; exposed errors |
| 9 | Cron runs and no jobs are stuck | Check cron_schedule for errors and long-pending jobs | Stale indexes, unsent emails, missed exports |
| 10 | Upgrade blockers are known | Run Adobe's Upgrade Compatibility Tool (Adobe Commerce) or a static analysis against the target version | Upgrade estimates turn out wrong |
2. Performance (10 checks)
| # | Check | How to check | What a fail costs |
|---|---|---|---|
| 11 | Core Web Vitals pass on mobile field data | Search Console Core Web Vitals report or CrUX: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 | Weaker user experience and conversion; ranking signal lost |
| 12 | Full page cache is enabled and uses Varnish | Stores > Configuration > Advanced > System > Full Page Cache | Every visit hits PHP; slow pages under load |
| 13 | Key pages are actually cacheable | Check response headers on category and product pages for cache hits | One cacheable="false" block disables caching for a whole page |
| 14 | Server response time is healthy | Measure time to first byte on cached and uncached pages | Slow LCP regardless of frontend work |
| 15 | Indexers run on schedule, not on save | bin/magento indexer:show-mode | Slow admin saves; locked tables during imports |
| 16 | Images are resized, compressed and lazy-loaded below the fold | Lighthouse and the network panel on product and category pages | Poor LCP; high bandwidth |
| 17 | Third-party scripts are justified and loaded late | List tags in the page source and tag manager; check each owner | Poor INP; privacy risk |
| 18 | Search runs on a supported OpenSearch version | Check the configured engine and version | Unsupported service; slow or broken search |
| 19 | Cache and sessions use Valkey or Redis, not the file system | Check app/etc/env.php cache and session settings | Slow pages and lock contention at peak |
| 20 | Store has been load tested for peak traffic | Ask for the last load test results | Outage on your best sales day |
For the fixes behind these checks, see our Magento speed optimization guide.
3. SEO (10 checks)
| # | Check | How to check | What a fail costs |
|---|---|---|---|
| 21 | Important pages are indexed | Search Console page indexing report | Products invisible in search |
| 22 | Layered navigation URLs do not create crawl traps | Crawl a category with filters; check robots rules and canonicals | Crawl budget wasted on duplicates |
| 23 | Canonical tags are set for products and categories | Stores > Configuration > Catalog > Search Engine Optimization | Duplicate content across paths |
| 24 | XML sitemap is generated and submitted | Marketing > Site Map; Search Console sitemaps report | Slower discovery of new products |
| 25 | Titles and meta descriptions are unique on key templates | Crawl with an SEO crawler and sort duplicates | Lower click-through |
| 26 | Product structured data is valid | Google Rich Results Test on sample products | No price or availability in results |
| 27 | Out-of-stock and discontinued products are handled deliberately | Review settings and a sample of old URLs | Soft 404s and lost link equity |
| 28 | Redirects have no chains or loops | Crawl URL rewrites and old URLs | Slower crawling; diluted signals |
| 29 | Category pages have useful, unique copy | Review top categories by traffic | Thin pages that rank poorly |
| 30 | Store views use correct hreflang, if multilingual | Inspect page source on each locale | Wrong language shown in search |
Our Magento SEO checklist goes deeper on each of these.
4. Security (10 checks)
| # | Check | How to check | What a fail costs |
|---|---|---|---|
| 31 | Admin uses a non-default URL | Check whether /admin or /backend loads the login page | Constant brute-force attempts |
| 32 | Two-factor authentication is enforced for all admin users | Review the 2FA configuration and user list | Account takeover from a leaked password |
| 33 | Admin users and roles follow least privilege | System > Permissions; remove ex-staff and shared logins | Insider and ex-employee risk |
| 34 | Adobe's Security Scan reports no critical issues | Run the free Security Scan from your Commerce account | Undetected malware or known risks |
| 35 | No unknown files or scripts in the web root or database content | Compare files with the repository; search CMS blocks for unknown scripts | Card skimming and data theft |
| 36 | Content Security Policy is configured | Check CSP headers and the report-only status on checkout pages | Injected scripts go unnoticed; payment-page compliance gaps |
| 37 | HTTPS everywhere with HSTS | Check headers and mixed-content warnings | Data exposure; browser warnings |
| 38 | Backups run and a restore has been tested | Ask for the last successful restore date | Long outage after an incident |
| 39 | Server and SSH access use keys and are logged | Review access lists and logs with your host | Untraceable changes |
| 40 | A web application firewall and rate limiting are active | Confirm with your host or CDN | Bot abuse, card testing and scraping |
Admin hardening is the cheapest security win; our Magento admin security guide walks through it.
5. Extensions (10 checks)
| # | Check | How to check | What a fail costs |
|---|---|---|---|
| 41 | Every enabled module is known and needed | List modules in app/etc/config.php; ask who uses each | Dead code still loaded and patched |
| 42 | Disabled modules are removed, not just disabled | Compare config.php with composer.json and app/code | Upgrade conflicts from code nobody uses |
| 43 | Each vendor extension supports your target Magento and PHP versions | Check vendor changelogs and compatibility pages | Upgrade blocked waiting for vendors |
| 44 | Extensions are installed through Composer | Look for vendor code copied into app/code | Manual, error-prone updates |
| 45 | Licences and support subscriptions are current | List renewal dates | No security fixes from the vendor |
| 46 | No two extensions solve the same problem | Group modules by function | Conflicts and double overhead |
| 47 | Extensions do not break full page cache | Profile pages with each module's features active | Silent performance loss |
| 48 | Storefront extensions match your theme (Luma, Hyvä or headless) | Check for compatibility modules | Broken features after a theme change |
| 49 | Vendor code has not been edited in place | Diff vendor packages against their releases | Fixes lost on the next vendor update |
| 50 | Features now in core are not duplicated by extensions | Compare with core features such as Page Builder, 2FA and reCAPTCHA | Paying for and patching what you already have |
6. Data and integrations (10 checks)
| # | Check | How to check | What a fail costs |
|---|---|---|---|
| 51 | Database size is understood, and log tables are cleaned | List the largest tables | Slow backups, deploys and queries |
| 52 | Product attributes are consistent and not duplicated | Review attribute sets and unused attributes | Messy filters and imports |
| 53 | Each data type has one source of truth | Map where products, prices, stock and customers are mastered | Overwrites and mismatched prices |
| 54 | Integrations log errors and alert someone | Ask how a failed order export is noticed | Lost orders discovered by customers |
| 55 | Integrations use queues or cron, not page requests | Review integration code and message queue consumers | Slow checkout when a partner system is slow |
| 56 | Analytics and conversion tracking match order data | Compare a week of orders with analytics revenue | Bad marketing decisions |
| 57 | Personal data retention follows your policy | Check old customers, quotes and logs | Privacy compliance exposure |
| 58 | Transactional emails send and are authenticated | Test order emails; check SPF, DKIM and DMARC | Emails in spam; support load |
| 59 | Payment methods and refunds reconcile with the provider | Compare a month of payments with provider reports | Revenue leakage |
| 60 | Documentation exists for integrations and custom modules | Ask for it | Every new developer starts from zero |
Turning results into a plan
- Fix now: any security fail (31 to 40), unsupported versions (1 to 3) and broken integrations (54).
- Fix before new development: upgrade blockers, core edits, extension conflicts and cache-breaking modules.
- Schedule: performance and SEO fails, ordered by revenue impact on your top templates.
- Document: unknowns become owned tasks with a named person.
Some teams run this audit once and hand the results to whoever builds next. Others fold it into ongoing Magento support and maintenance, so the checks repeat with each release. Where performance fails dominate, a focused Magento performance optimization project usually pays back first; where SEO fails dominate, start with Magento SEO work on your highest-traffic templates.
FAQ
How long does a Magento audit take?
It depends on store size, the number of extensions and integrations, and how much access is available. A store with complete access and documentation is much quicker to audit than one where nobody knows what each module does.
Can I run the audit myself?
Many checks, especially in SEO, security settings and performance, need only admin access and free tools. Code, extension and integration checks need a Magento developer.
Should the agency that will do the work also do the audit?
It can, but ask for the raw findings, not only a proposal. A clear audit report is useful to any team, which keeps you free to choose.
Sources
Adobe Commerce lifecycle policy (Adobe Experience League); Security best practices (Adobe Commerce Implementation Playbook); Security Scan (Adobe Experience League); Upgrade Compatibility Tool overview (Adobe Experience League); Core Web Vitals (web.dev).
