Magento SEO Audit: A Practical Checklist for Your Store
Key Takeaways
- A Magento SEO audit should test which URLs search engines can crawl, index, and treat as canonical before reviewing content or metadata.
- Layered navigation can create thousands of low-value parameter URLs, so compare the number of crawlable URLs with the actual number of products and categories.
- Test Core Web Vitals by page template, including home, category, product, search, and CMS pages. A store-wide average can hide template-specific problems.
- Record every finding with evidence, affected URL patterns, priority, owner, and validation criteria. This turns the audit into an executable remediation plan.
- Repeat focused audits after migrations, theme changes, extension updates, catalog restructures, and large product imports.
Why Magento Needs a Specific Audit
A Magento SEO audit is not a generic scan for broken links and missing titles. Magento and Adobe Commerce stores can generate multiple paths to the same product, parameter-based filter combinations, store-view variations, and accumulated URL rewrites. For a broader overview of the platform's SEO landscape, see the complete Magento SEO guide.
These systems interact. A layered navigation setting can increase the number of crawlable URLs. Those URLs may then carry inconsistent canonicals, consume crawl resources, and appear in search reports as crawled but not indexed.
An SEO audit should remain separate from code and security audits. Performance profiling may reveal backend bottlenecks, but the SEO audit focuses on how technical behavior affects crawling, indexing, ranking, and search-result presentation.
Use a testable audit record rather than a collection of screenshots. Each finding should include:
- Issue: What is wrong?
- Evidence: Which report, crawl, or page confirms it?
- Scope: Which URL pattern, store view, or template is affected?
- Impact: Does it affect discovery, indexation, relevance, speed, or reporting?
- Action: What configuration or template change is required?
- Validation: How will the team confirm the fix?
- Owner: Does the task belong to SEO, development, merchandising, or infrastructure?
Phase 1: Crawlability and Indexation
Start by defining which page types should appear in search. For most stores, this includes selected category, product, CMS, and editorial pages. Checkout steps, customer account pages, internal search results, and many filtered combinations usually do not need to rank.
flowchart TD
A["Start SEO audit"] --> B["Phase 1: Crawl\nand indexation"]
B --> C["Phase 2: Layered\nnavigation analysis"]
C --> D["Phase 3: Canonical\nverification"]
D --> E["Phase 4: Core Web\nVitals by template"]
E --> F["Phase 5: Redirects\nand HTTPS"]
F --> G["Phase 6: Content\nand metadata"]
G --> H["Phase 7: Hreflang\nand structured data"]
H --> I["Prioritize and\nremediate"]Compare inventory with crawl volume
Export the number of active products, categories, CMS pages, and store views. Compare that inventory with the number of URLs discovered by a crawler and reported by search engines.
A large difference does not prove a problem, but it indicates where to investigate. For example, a store with 20,000 active products should not automatically produce hundreds of thousands of indexable product and filter URLs.
Review indexation reports
Inspect search engine indexation reports by reason and URL pattern. Pay particular attention to URLs classified as crawled but not indexed, duplicate without a selected canonical, blocked by robots.txt, soft 404, and redirect.
Do not treat every excluded URL as an error. Exclusion is correct when the URL has no independent search value. The audit should determine whether each exclusion matches the intended indexation policy.
Crawl the store as a search engine
Run a full crawl and segment the results by page type. Record response codes, indexability, canonical targets, title tags, meta descriptions, headings, pagination signals, and crawl depth.
Look for URL patterns rather than isolated errors. Common patterns include parameter URLs, internal search pages, obsolete category paths, mixed URL suffixes, and products reachable through several category routes.
Inspect XML sitemaps
Check that each sitemap contains canonical, indexable URLs that return a successful response. Filtered navigation, checkout, account, internal search, redirecting, and error URLs should not appear.
For multi-store installations, verify that the correct URLs appear for each store view. Compare a sitemap sample with the rendered canonical tags and final redirect destinations.
Review robots.txt carefully
Confirm that robots.txt blocks known low-value areas without preventing search engines from rendering important pages. A robots.txt rule controls crawling, not guaranteed removal from an index.
Check parameter patterns individually. A broad rule intended to block sorting parameters can accidentally block valuable category or product paths if the pattern is too general.
Crawlability checklist
- Define the page types that should and should not be indexed.
- Compare active catalog counts with crawlable and indexed URL counts.
- Segment indexation reports by URL pattern and exclusion reason.
- Confirm that XML sitemaps contain only canonical, indexable URLs.
- Check robots.txt against real store URL patterns.
- Test whether important pages are reachable through internal links.
- Record crawl depth for priority products and categories.
Phase 2: Layered Navigation
Layered navigation is one of the most important Magento-specific audit areas. Every filter, sort option, and parameter can create another URL. When filters combine, the number of possible URLs grows quickly. For a full treatment of filter URL strategy, see Magento faceted navigation and duplicate content.
A category with five colors, six sizes, and three materials can produce 90 combinations before sorting, price ranges, pagination, or multiple filter selections are considered. Across 50 categories, those three filters alone can create 4,500 combinations.
Map all parameter types
Start by listing the parameters created by filters, sorting, view mode, pagination, price ranges, and search functions. Record whether each parameter changes the products shown, changes only their order, or produces an empty result.
| URL type | Audit question | Likely treatment |
|---|---|---|
| Single useful filter | Does the page match distinct search demand and contain enough products? | Consider a controlled landing page if commercially justified |
| Combined filters | Does the combination provide independent search value? | Usually restrict indexation unless deliberately managed |
| Sort and direction | Does changing order create a meaningfully different page? | Avoid separate indexation |
| Pagination | Can crawlers reach products beyond the first page? | Keep discovery paths consistent and test canonical behavior |
| Empty filter result | Does the URL return a valid page with no products? | Remove internal discovery and prevent indexation |
Measure the scale
Use crawler exports and indexation reports to count URLs by parameter. Compare those counts with sessions, impressions, conversions, and indexed status where data is available.
The goal is not to block every filtered URL. It is to distinguish valuable landing pages from low-value combinations. Make that decision by URL pattern instead of manually reviewing thousands of pages.
Check internal discovery
Inspect category templates, navigation widgets, pagination, and filter links. A URL can remain easy for crawlers to discover even when it is absent from the sitemap.
Review the rendered HTML, not only the visible interface. Some themes and extensions create crawlable links that are difficult to notice during manual browsing.
Layered navigation checklist
- Inventory every filter, sorting, pagination, and view parameter.
- Count discovered URLs for each parameter pattern.
- Identify empty, near-empty, and duplicate result combinations.
- Check whether filtered URLs appear in XML sitemaps.
- Review canonical and robots behavior for representative combinations.
- Confirm that useful filtered landing pages have a deliberate indexation policy.
- Test whether extensions override standard Magento behavior.
Phase 3: Canonical Verification
Magento stores can expose one product through several category paths or URL variants. Canonical tags help search engines identify the preferred version, but configuration alone is not proof that every template outputs the correct tag. For detailed canonical configuration guidance, see Magento canonical tags and canonical URLs.
Build a canonical test matrix
Test representative URLs from each page type. Include products reached directly and through category paths, categories, filtered categories, paginated pages, search results, CMS pages, and store-view variants.
| Check | Pass condition |
|---|---|
| Canonical presence | The intended indexable templates output one canonical tag |
| Canonical status | The target returns a successful response |
| Protocol and host | The target uses the preferred HTTPS and hostname format |
| Indexability | The canonical target is not blocked or marked noindex |
| Redirect alignment | The canonical does not point to a URL that redirects elsewhere |
| Store-view alignment | The target belongs to the correct language and regional store view |
Export canonical relationships
Use a crawler to export source URLs and canonical targets. Group the data by template and URL pattern, then investigate missing tags, conflicting tags, targets with errors, and large groups pointing to an unexpected page.
Pay special attention to canonical chains. If page A declares page B as canonical and page B redirects to page C, the configuration sends avoidable mixed signals.
Canonical checklist
- Test direct and category-path product URLs.
- Verify canonicals on categories, filters, pagination, and CMS pages.
- Confirm canonical targets return a successful response.
- Check that canonical targets are indexable.
- Match protocol, hostname, path, and store view.
- Find canonical chains, loops, and cross-language targets.
- Compare declared canonicals with search engines' selected canonicals.
Phase 4: Core Web Vitals
Do not judge Magento performance from one homepage test. Audit each major template because product galleries, category grids, navigation extensions, promotional banners, and third-party scripts create different performance profiles.
The Magento audit research from Webpulse uses the standard Core Web Vitals targets of LCP below 2.5 seconds, CLS below 0.1, and INP below 200 milliseconds. Use field data where available because it reflects real devices, networks, and user interactions.
| Metric | Target | Magento audit focus |
|---|---|---|
| LCP | Below 2.5 seconds | Server response, full-page caching, hero media, product images, and render-blocking resources |
| CLS | Below 0.1 | Missing image dimensions, late banners, consent layers, fonts, and dynamic product blocks |
| INP | Below 200 milliseconds | Large JavaScript workloads, navigation interactions, product options, and third-party scripts |
Test by template and device
Create a sample that includes the homepage, a large category, a small category, a configurable product, a simple product, an out-of-stock product, a CMS page, and an internal search result. Test both mobile and desktop behavior.
Choose pages with real traffic where possible. A fast low-traffic product page does not offset a slow category template used by most visitors.
Separate frontend and backend causes
Slow server response can delay every resource that follows. Review caching behavior, uncached requests, extensions, database work, and infrastructure separately from image weight and browser-side JavaScript.
Performance tools can identify symptoms, while application monitoring and profiling can help developers isolate backend causes. Keep the SEO finding connected to the affected templates and user metrics rather than turning the report into a general code review.
Core Web Vitals checklist
- Collect field data and lab tests for each major template.
- Test mobile and desktop separately.
- Review full-page caching and time to first byte.
- Find oversized product, category, and promotional images.
- Check width and height attributes for media and dynamic blocks.
- Measure JavaScript execution and third-party script cost.
- Retest the same page sample after changes.
Phase 5: Redirects and HTTPS
Magento's URL rewrite data can grow as products, categories, and URL keys change. An audit should identify redirect chains, loops, broken targets, outdated rewrites, and conflicting routes. For URL configuration best practices, see Magento URL structure and redirects.
Test URL consistency
Choose one preferred version for HTTPS, hostname, trailing slash behavior, and any configured suffix. Every alternative should resolve predictably to the preferred URL without unnecessary intermediate redirects.
Check internal links, sitemaps, canonicals, hreflang annotations, and structured data for the same preferred format. Redirects can correct external requests, but internal systems should link directly to the final URL.
Review changed and deleted entities
Sample products and categories that were renamed, moved, disabled, or removed. Determine whether each old URL redirects to a close replacement, returns an intentional not-found response, or enters an irrelevant redirect path.
Avoid sending every discontinued product to the homepage. Redirect only when a useful equivalent or parent destination meets the visitor's likely intent.
Redirect and URL checklist
- Test HTTP, HTTPS, www, and non-www variants.
- Check trailing slash and suffix consistency.
- Crawl redirect chains, loops, and erroring targets.
- Review rewrites created by catalog and category changes.
- Update internal links to point directly to final URLs.
- Align sitemaps, canonicals, hreflang, and structured data with final URLs.
- Sample deleted and discontinued product behavior.
Phase 6: Content and Metadata
Technical fixes establish which pages can rank. The next phase checks whether indexable pages clearly describe their products, categories, and search intent. For product-specific SEO guidance, see Magento product page SEO and metadata. For insights on how catalog data quality affects onsite search and conversion, see Magento search optimization and onsite search.
Audit by page type
Export URL, title, meta description, H1, canonical, status, word count, and page type. Group findings by template and category rather than treating every duplicate field as an isolated writing task.
Common patterns include titles generated from the same short product name, category descriptions repeated across store views, missing product attributes, and metadata inherited from incomplete source records.
Check content against catalog data
Product content cannot be more accurate than the underlying catalog. Review whether names, brands, identifiers, dimensions, materials, compatibility data, and availability fields are complete and consistent.
When a pattern affects hundreds of pages, handle it as a structured data workflow. Export the affected fields, analyze the gaps, transform approved rows, validate the output, review exceptions, and merge only safe changes. The catalog content workflow shows how this controlled process can be organized.
Validate at scale
Do not approve bulk metadata solely because every field is populated. Add checks for length, duplication, unsupported claims, missing attributes, prohibited terms, and language mismatches.
Keep prompts, transformation rules, validators, and outputs visible to the catalog team. This makes failures easier to trace and reduces dependence on a black-box generation process.
On-page checklist
- Find missing, duplicate, truncated, and generic titles.
- Check that each indexable page has one clear H1.
- Compare metadata with the visible page content.
- Review category copy for useful selection guidance.
- Check product content against structured catalog fields.
- Find copied manufacturer text and near-duplicate descriptions.
- Confirm language consistency across each store view.
- Validate bulk changes before importing them into Magento.
Phase 7: Hreflang and Structured Data
Multi-store installations require extra checks because store views may represent languages, regions, currencies, or separate catalogs. Hreflang and structured data must reflect the actual relationship between these pages.
Audit hreflang clusters
Choose representative products, categories, and CMS pages from every store view. Verify that each alternate URL returns a successful response, declares the correct language or regional code, and references the other members of the cluster.
Check reciprocity. If the German page names the English page as an alternate, the English page should name the German page. Do not include redirected, blocked, canonicalized-away, or unavailable URLs in the cluster without reviewing the intended behavior.
Check canonical alignment
A localized page should not normally declare a different language version as canonical when the localized page is intended to rank independently. Compare canonicals and hreflang annotations in the same audit export.
Validate structured data
Inspect the rendered markup on representative product, category, and content templates. Product markup should match the visible product name, availability, price, currency, brand, and identifiers when those fields are present. For a detailed guide to Magento structured data, see Magento schema markup and structured data.
Check whether configurable products, sale prices, multiple currencies, out-of-stock items, reviews, and variants produce accurate output. Do not assume that an extension remains correct after a theme or catalog configuration change.
Hreflang and structured data checklist
- Map each store view to its intended language and region.
- Check hreflang reciprocity across representative clusters.
- Remove broken, redirected, or non-indexable alternates.
- Align canonicals with localized indexation goals.
- Validate rendered structured data by template.
- Compare product markup with visible prices and availability.
- Test variants, sale pricing, currencies, reviews, and stock states.
- Retest after theme, extension, or catalog changes.
Magento SEO Audit Checklist Summary
Run the audit in dependency order. Fixing metadata before resolving duplicate URLs can waste effort because search engines may index a different version of the page.
- Define indexation policy: Decide which page types and URL patterns should rank.
- Crawl the store: Export response codes, indexability, canonicals, metadata, and crawl depth.
- Compare URL counts: Reconcile catalog inventory, crawler discoveries, sitemaps, and indexation reports.
- Diagnose parameters: Measure layered navigation, sorting, pagination, and search URL patterns.
- Verify canonicals: Test targets, status codes, indexability, protocol, hostname, and store view.
- Measure performance: Review Core Web Vitals by page template and device.
- Audit redirects: Find chains, loops, broken targets, and obsolete rewrites.
- Review content: Group metadata and catalog-content issues by page type and root cause.
- Test international signals: Check hreflang reciprocity and canonical alignment.
- Validate structured data: Compare rendered markup with visible product information.
- Prioritize remediation: Rank findings by affected URLs, organic opportunity, severity, and implementation effort.
- Retest: Repeat the original crawl and test sample after deployment.
Tools and Audit Resources
A practical Magento site audit usually combines several data sources. No single tool can show how configuration, rendered templates, search-engine behavior, and real-user performance interact.
- Search performance and indexation reports: Use them to review queries, indexed pages, exclusions, crawl activity, and search-engine-selected canonicals.
- SEO crawler: Export URL status, indexability, canonical targets, metadata, headings, links, and crawl depth.
- Core Web Vitals testing: Combine real-user field data with repeatable lab tests by template using PageSpeed Insights.
- Application monitoring: Use backend traces when slow response times require deeper diagnosis.
- Structured data validator: Test rendered markup on representative products and templates.
- Spreadsheet or table workflow: Join crawler exports, catalog records, analytics, and audit decisions by URL or product identifier.
The Promodo Magento audit checklist also frames the work across technical setup, content, and performance. Keep those workstreams connected through one issue register so fixes can be prioritized and retested consistently.
Turn Findings Into Safe Changes
An audit creates value only when findings become controlled changes. Assign each issue to a URL pattern, owner, release, and validation test. Preserve the original crawl and exports so the team can compare conditions before and after deployment. For implementing technical fixes based on audit findings, see Magento 2 SEO best practices and technical optimization. If you need external support to execute the remediation, see Magento SEO services.
For large metadata or catalog-content corrections, bulkbase.ai can process CSV-based fields through an analyze, transform, validate, exception-review, and safe-merge workflow. Teams retain control of prompts, validators, and outputs while using their own provider API keys.
To test this approach on a representative Magento export, book a guided demo. Booking the demo is the required first step to start and activate a free trial.
Get started for Free
Every trial starts with a free guided demo, what are you waiting for.
Repeat the full Magento SEO audit on a defined schedule and run focused reviews after migrations, theme changes, extension updates, catalog restructures, or large imports. These events can alter URLs, rendering, metadata, structured data, and internal links even when the storefront appears unchanged.
Frequently Asked Questions
How long does a Magento SEO audit take?
A focused audit of crawlability, canonicals, and indexation can take a few days for a small catalog. A full audit covering layered navigation, Core Web Vitals, hreflang, structured data, and content quality across multiple store views may take several weeks depending on catalog size and complexity.
What tools are needed for a Magento SEO audit?
A practical audit combines Google Search Console for indexation data, an SEO crawler for URL-level analysis, Core Web Vitals testing tools for performance, a structured data validator for schema, and server logs for crawl behavior. A spreadsheet workflow ties the findings together.
How often should I audit Magento SEO?
Run a full audit at least once per year and focused reviews after migrations, theme changes, extension updates, catalog restructures, and large product imports. These events can alter URLs, rendering, metadata, and internal links without obvious storefront changes.
What is the most important Magento SEO audit finding?
Layered navigation URL expansion is typically the highest-impact finding. Uncontrolled filter combinations can create thousands of low-value URLs that waste crawl budget and dilute indexing signals. Addressing this first often produces the largest improvement.
Should I fix canonical tags or content first?
Fix canonical and duplicate URL issues before investing in content optimization. Search engines may index a different version of a page than the one you optimized, which means the content work would not produce results until the URL structure is resolved.