Magento SEO Checks After a Deployment

Magento releases bundle config imports, extension updates, theme changes and cache flushes. Crawl before and after with the same scope and compare robots, canonicals and filter URL counts. See post-deployment SEO testing for the general method.

5 release types5 steps before deploying10 post-deploy checks1 baseline to compare

Magento · Config imports, extension updates, theme changes, reindexing and full page cache

A Magento deployment rarely changes one thing. A single release can run setup upgrades, import configuration, update extensions, compile code, deploy static content, reindex and flush the cache, and any of those steps can change what crawlers receive.

Treat every release as an SEO event. Crawl production with the same scope before and after, and compare URL counts, robots, canonicals and status codes by pattern.

Baseline crawl→Review config→Deploy→Warm cache→Crawl same scope→Compare

What can go wrong after a Magento deployment

Release content	Risk level	What usually breaks
Code fix, no config change	Low	Template edits remove a heading, schema block or canonical
Configuration import	Medium	Staging base URL, NOINDEX default robots or SEO settings copied to production
SEO or layered navigation extension update	High	Canonical and robots rules reset, filter links change, duplicate canonical tags
Theme change or upgrade	High	Breadcrumbs, schema, headings and toolbar links rebuilt differently
Magento version upgrade	High	All of the above, plus URL rewrite regeneration and changed defaults

Layers a release can change

ConfigurationBase URLs, default robots, catalog SEO settings imported from config filesSitewide noindex

ExtensionsSEO, layered navigation, sitemap and rich snippet modulesFacet explosion

ThemeCategory, product and toolbar templatesLost schema

CacheFull page cache or Varnish serving old or error pagesStale output

Crawl after the cache is flushed and warmed. A crawl against a stale cache can hide a regression for days.

Before deploying

Crawl production and save the audit with the same parameter scope and URL limit you will use afterwards.
List what the release contains. Code, configuration, extensions, theme and data each break different things.
Review config changes. Check config.php and environment files for base URLs, design robots settings and catalog SEO values.
Crawl staging if you can, with the same scope, and compare it against the production baseline.
Record versions of Magento, extensions and the theme so differences can be traced.

After deploying: what to check

Run these within the first hour, then crawl and compare in Audit Comparison.

Check	Expected result
Status codes	200 on sample URLs, no 503 left from maintenance mode
Canonical host	Production domain only, no staging base URL, via Custom Source Search
Default robots	INDEX,FOLLOW on pages indexable in the baseline
robots.txt	Production rules, no Disallow: /
Filter URLs	Same indexable count per parameter as the baseline
Canonical tags	One per page, same targets as the baseline
Old product URLs	Still 200 or one 301, rewrites intact
Product schema	Product, Offer and BreadcrumbList still valid
Sitemap	Regenerated with production URLs
Tracking	GA4 and pixels fire once, via Tracking & Pixel Audit

How to identify the scope

Every URL fails the same wayConfigurationSitewide noindex or wrong host point to an imported config value.

Filter URLs changedLayered navigation moduleCounts or robots moved on parameter URLs: the extension update.

One page type changedTheme templateOnly products or only categories lost schema or headings: a template.

Intermittent resultsCacheDifferent output on repeat fetches: full page cache or Varnish.

How to validate the fix

Fix configuration first, then flush and warm the full page cache.
Recrawl with the same scope and compare against the baseline.
Target: every difference is one the release planned.
Regenerate the sitemap and inspect key URLs in Search Console.
Schedule Scheduled SEO Audits after every release window.

0Unplanned differences from the baseline

0Staging hosts in canonicals or sitemaps

0New indexable filter URLs

Before and after example

Baseline crawl/women/tops.html → INDEX,FOLLOW
canonical: www.example.com
Indexable URLs: 11,240

→

After release/women/tops.html → NOINDEX,NOFOLLOW
canonical: staging.example.com
Indexable URLs: 0

Cause: the release imported configuration exported from staging, including its base URL and default robots. Restoring production values and flushing the cache fixes every page.

Common mistakes

Exporting configuration from staging without filtering environment values. Base URLs and robots settings travel with it.
Crawling before the cache is warm. You test the old pages, not the release.
Updating SEO and layered navigation extensions with no recrawl. These modules control the riskiest output in the store.
Checking only the homepage. Regressions show up on categories, filters and products.
Changing crawl scope between baseline and comparison. Different scopes produce different numbers for unrelated reasons.
Leaving maintenance mode on longer than needed. Long stretches of 503 responses can slow crawling.

Every release gets a crawl

Magento releases bundle configuration, extensions, themes and cache changes together. Save a baseline with a fixed scope, deploy, warm the cache, crawl again and compare. Most Magento SEO incidents are one imported setting or one updated module that nobody recrawled.