The 12-Point Magento 2 Audit Checklist: Signs Your Store Needs Help

12-Point Magento 2 Audit Checklist: Self-Diagnose Your Store

Most Magento 2 store owners suspect something is wrong long before they can name what it is.

The site feels slower than it used to. The previous developer mentioned "the cron is acting up" but never explained. PageSpeed scores dropped two months ago and nobody got around to investigating. The admin panel hangs sometimes. Customers occasionally email about checkout errors that nobody can reproduce.

Individually, none of these are urgent. Collectively, they're the early signs of a store that's drifting toward a serious Magento 2 rescue project.

This is the 12-point Magento audit checklist we run before taking on any rescue or migration project. It's organized into four categories — performance, security, SEO, and code health — with three checks each. You can work through it yourself in under an hour, no developer access required for most of it.

I'm Vlad Kozak, founder of StageM. We've used a version of this checklist on 70+ Magento projects since 2018, and I covered the methodology behind it in my talk at Magento Meet Ukraine 2025. Below is the practical version you can apply to your own store today.

How to Use This Checklist

Each item below has three parts:

• What to check — the specific thing to look at

• What "good" looks like — the healthy state

• Red flag — what means you have a problem

Score yourself: 0-2 red flags is normal maintenance territory. 3-5 means you're carrying meaningful technical debt. 6+ means your store is actively losing you money, and a structured audit is the right next step.

Let's go.

Category 1: Performance Health

1. Magento Application Mode

What to check: Run php bin/magento deploy:mode:show in your Magento root, or ask your developer to confirm. Magento has three modes: default, developer, and production.

What "good" looks like: Production mode. This is the only acceptable mode for a live store.

Red flag: Developer mode in production. We see this surprisingly often — a developer set the mode for debugging months ago and never switched it back. Every page load runs slower than it should, every static asset is regenerated on the fly, and your error logs balloon with verbose debugging output.

Real example: One store we audited had been running in developer mode for 14 months. Their PageSpeed score jumped from 38 to 71 within a day of switching to production mode and clearing the cache. Nothing else changed.

2. PageSpeed Insights and Core Web Vitals

What to check: Run PageSpeed Insights on your homepage, a category page, and a product page. Check both desktop and mobile.

What "good" looks like: PageSpeed scores above 75 desktop and 60 mobile. Core Web Vitals (LCP, INP, CLS) all in the "good" range — green, not orange or red.

Red flag: Scores in the red zone (below 50) on mobile. This is correlated with both lower conversion rates and lower search rankings. Google's documentation is explicit: Core Web Vitals are a ranking factor.

For deeper diagnosis, look at the field data section in PageSpeed Insights — the chrome user experience report data shows what your real visitors are experiencing, not just synthetic test results.

3. Server Response Time and Caching

What to check: Time to First Byte (TTFB) on uncached pages. You can see this in PageSpeed Insights under "Server response time" or in your browser's DevTools Network tab.

What "good" looks like: TTFB under 600ms on uncached requests. Under 200ms on cached requests served by Varnish or similar.

Red flag: TTFB above 1.5 seconds, or no full-page caching configured at all. We've audited stores running entirely on file-based cache where the homepage took 3+ seconds just to start sending data to the browser.

Real example: One client's /var directory had grown to fill 100% of their disk because they were storing Varnish cache there with no rotation. The site was throwing 503 Backend fetch errors because the cache had nowhere to write. Twenty minutes of cleanup and proper Varnish configuration restored service.

Category 2: Security and Stability

4. Magento Version and Patch Level

What to check: Run php bin/magento --version or check Stores → Configuration in admin. Compare against the latest Magento releases.

What "good" looks like: Magento 2.4.7 or newer. Magento 2.4.8 (released April 2025) is the current version as of this writing.

Red flag: Anything below 2.4.4. If you're on Magento 1, that's not a red flag — it's an emergency. Magento 1 reached end-of-life in June 2020. No security patches, no compatibility updates, no support.

The gap between your version and current matters because security patches are not backported indefinitely. Older versions accumulate known unpatched vulnerabilities that attackers actively scan for.

5. Cron Health

What to check: Look at the cron_schedule table in your database. Count rows by status:

SELECT status, COUNT(*) FROM cron_schedule GROUP BY

SELECT status, COUNT(*) FROM cron_schedule GROUP BY

SELECT status, COUNT(*) FROM cron_schedule GROUP BY

SELECT status, COUNT(*) FROM cron_schedule GROUP BY

What "good" looks like: Mostly success and small numbers of pending. Few or zero running rows older than a couple of hours. Total table size under 100,000 rows.

Red flag: Thousands of running rows that never completed. Tables in the millions of rows. Large numbers of missed jobs. Any of these mean cron is broken and silently failing — emails aren't sending, indexers aren't updating, and customer-facing functionality is degrading without anyone noticing.

Real example: We've seen cron_schedule tables grow to over 4 million rows. Every cron tick was scanning all of them just to find pending jobs. CPU usage was sitting at 99% from cron alone before we cleaned it up.

For the full deep dive, see our Magento 2 cron optimization guide.

6. Backups and Recovery

What to check: Confirm that backups are running automatically, that they include both database and files, and — most importantly — that someone has actually tested restoring from a backup recently.

What "good" looks like: Automated daily database backups, weekly full file backups, both stored offsite (different server or cloud storage). At least one successful restore test in the last six months.

Red flag: "I think the hosting company does backups." If you can't point to a specific backup from yesterday and describe the exact process for restoring it, you don't have backups. You have hopes.

The riskiest stores we audit have been running for years with no verified backups. When something eventually goes wrong — and it will — recovery takes days instead of hours, and sometimes the data is permanently lost.

Category 3: SEO and Visibility

7. Indexation Health in Google Search Console

What to check: Open Google Search Console, look at the Indexing report. Compare "Indexed" pages against your sitemap submission.

What "good" looks like: Indexed page count roughly matches your sitemap. Most pages report "Submitted and indexed."

Red flag: Massive divergence between sitemap and indexed pages. Categories with "Discovered - currently not indexed" or "Crawled - currently not indexed" status. Sudden spikes or drops in indexed page count.

Real example: One store we audited had 122,000 pages indexed when their sitemap only listed 8,000 product pages. The cause: internal search URLs (catalogsearch/result/?q=...) had become indexed, creating tens of thousands of low-quality duplicate pages. Search rankings had dropped 40% in three months.

8. Sitemap, Robots, and Canonical Configuration

What to check: Visit yourstore.com/sitemap.xml and yourstore.com/robots.txt. View source on a few category and product pages and search for rel="canonical".

What "good" looks like: Sitemap loads, lists current products and categories, updates regularly. Robots.txt blocks admin paths and allows everything else. Every product and category page has a canonical tag pointing to its own clean URL.

Red flag: No sitemap, sitemap with 404 errors, robots.txt that accidentally blocks important paths, or canonical tags pointing to wrong URLs (or missing entirely). Multi-store setups should also have proper hreflang tags — most don't.

9. Analytics Data Integrity

What to check: Open Google Analytics 4. Compare GA4 ecommerce data against your Magento admin reports for the same period — orders, revenue, transactions.

What "good" looks like: GA4 numbers within 5-10% of Magento admin numbers. All ecommerce events firing correctly: view_item, add_to_cart, begin_checkout, purchase.

Red flag: GA4 showing significantly different revenue from Magento (more than 15% off). Missing events. purchase events not firing. Duplicate events.

If your analytics is wrong, every marketing decision based on it is wrong too. We've seen stores running paid ads against GA4 audiences for months while the underlying tracking was misconfigured. The marketing budget was effectively burning.

Category 4: Code and Module Health

10. Extension Audit

What to check: Run php bin/magento module:status to list all modules. Cross-reference active modules against actual business need.

What "good" looks like: Every active module serves a clear purpose. No abandoned extensions from years ago. No modules from vendors that have gone silent.

Red flag: 50+ third-party extensions, multiple modules doing similar things (two SEO modules, three image optimizers), or modules from developers who haven't released updates in 2+ years.

Each unmaintained extension is a potential security vulnerability and a guaranteed source of compatibility issues during your next Magento upgrade. The most expensive Magento upgrades we've quoted were almost entirely the cost of dealing with abandoned extensions, not the upgrade itself.

11. Custom Code in Core

What to check: Ask your developer (or a third-party reviewer) whether any modifications have been made to Magento core files — files inside vendor/magento/. The right answer is "no, all customizations are in custom modules."

What "good" looks like: All customizations live in app/code/ modules. Composer can be used to update Magento without conflicts.

Red flag: "Yeah, we edited a couple of files in vendor to make X work." This is the single most expensive piece of technical debt you can carry. Every Magento upgrade has to manually merge those changes. At some point, the cost of maintaining custom-modified core exceeds the cost of rebuilding.

This is one of the three signals we use to recommend rebuild over rescue.

12. Server and Database Resource Usage

What to check: Look at your server monitoring (your hosting provider's panel, or tools like New Relic, Hetrix, or even basic top). Check CPU, RAM, and disk usage trends over the past month.

What "good" looks like: CPU averages under 60%, with peaks not sustained above 90%. RAM under 80%. Disk usage under 80% with a clear growth trajectory. MySQL max_connections not regularly hit.

Red flag: Sustained CPU above 80%, frequent "Too many connections" errors in logs, disk approaching full, swap memory in use. Any of these mean your store has outgrown its current infrastructure.

Real example: One store kept throwing SQLSTATE[HY000] [1040] Too many connections errors at peak hours. The MySQL max_connections was set to a default value from years ago, while traffic had tripled since. The fix took 30 minutes of configuration work.

Scoring Your Store

Count your red flags from the 12 checks above:

0-2 red flags — Healthy. Your store is in good shape. Standard maintenance and quarterly check-ins are sufficient.

3-5 red flags — Technical debt accumulating. You have meaningful issues that aren't urgent yet but will compound. This is the right time for a structured audit and a phased optimization plan.

6-8 red flags — Active revenue risk. Your store is losing money you can't see — slower conversions, lower search rankings, customers churning to faster competitors. This is reanimation territory.

9+ red flags — Critical. Multiple foundational issues. The store is functional but at risk of major failure. You need professional intervention, and you may need to consider whether rescue or rebuild is the right path.

What a Professional Audit Adds (Beyond This Checklist)

This 12-point checklist gives you a meaningful diagnostic of your Magento 2 store. It's the same starting point we use internally before any rescue project.

What it doesn't replace is a full professional audit, which adds:

Code-level profiling. Tools like Blackfire and New Relic identify which specific PHP functions, database queries, and modules are consuming execution time on every request. You can't do this from outside the codebase.

Database deep analysis. Slow query logs, missing indexes, table fragmentation, replication lag — these require direct database access and experience reading MySQL internals.

Security scanning. Automated and manual checks for known CVEs, suspicious admin activity, malware signatures, and the specific vulnerability patterns that target Magento stores.

Custom code review. Reading through app/code and vendor/ for problematic patterns: ObjectManager misuse, missed dependency injection, plugin conflicts, observer overuse.

Prioritized roadmap. Not just "here are the problems" but "here's the order to fix them and the estimated effort and impact for each."

A professional audit typically takes 1-2 weeks and delivers a written assessment that you own — regardless of whether you continue with the agency that did it.

Want this audit run on your store? Book a 30-minute discovery call — we'll review your current setup and recommend whether a paid audit is the right next step.

Prefer to start with a structured self-assessment? Download our Practical Magento 2 Reanimation Plan — the expanded version of this checklist as a printable PDF.

Where to Go from Here

If you scored in the "healthy" range — great. Save this checklist and run it again in six months. Magento stores drift; what's healthy now will need re-checking.

If you scored 3-5, you're in the largest group: stores with real but manageable problems. The right move is a structured audit, then phased fixes. Don't try to fix everything at once.

If you scored 6+, the situation is more urgent. Read How to Rescue a Magento 2 Store Without Rebuilding It — our four-stage framework for stores in your position.

Either way, the worst response is to ignore the checklist. Magento problems compound. A 4-flag store today becomes an 8-flag store in twelve months without intervention.