Your Deploy Passed Every Test. Did It Just Break Your SEO?

Rem Barquilla — Tue, 20 Oct 2026 03:25:40 +0000

A website can pass unit tests, integration tests, and visual QA and still ship technical SEO problems. A deployment might change canonical URLs, break redirects, carry a staging noindex into production, strip structured data from a template, or create broken internal links. None of these fail a build. All of them can quietly drain search traffic for weeks before anyone notices.

Running a technical SEO check before and after every deployment helps you catch these regressions while they are still cheap to fix.

The Classic Deploy Disasters

Most deploy-related SEO incidents fall into a few familiar patterns:

Staging robots.txt shipped to production. A Disallow: / meant to keep staging out of search ends up live, blocking crawlers from the whole site.
Leftover noindex directives. A meta robots tag or X-Robots-Tag header from the staging environment survives the release.
Template changes that remove signals. A refactored layout drops the canonical tag, the title, hreflang annotations, or JSON-LD structured data.
Routing changes that break URLs. A new permalink structure, trailing-slash rule, or framework migration turns working URLs into 404s or long redirect chains.
Client-side rendering surprises. After moving from server-side rendering to client-side rendering, content and internal links may only appear after JavaScript runs.
Soft 404s. Error pages that return HTTP 200, so monitoring sees success while users and crawlers see nothing useful.

A good checklist targets exactly these failure modes.

Before Deployment: Establish a Baseline

Crawl the current production site and save the results. This is your reference point for spotting unexpected changes.

[ ] Record HTTP status codes for important URLs.
[ ] Save the current robots.txt.
[ ] Record title tags, meta descriptions, and H1 headings.
[ ] Record canonical URLs and hreflang tags.
[ ] Check meta robots tags and X-Robots-Tag headers.
[ ] Note which pages carry structured data (JSON-LD) and which schema types.
[ ] Review redirects: types (301 vs 302), destinations, and chain length.
[ ] Verify XML sitemap URLs return 200 and are indexable.
[ ] Check for broken internal links.
[ ] Save the full crawl for comparison.

If you can, crawl the staging environment too, with its crawl blockers temporarily bypassed for your own crawler. Catching a regression on staging is better than catching it in production.

For a full baseline crawl, a desktop crawler like SiteAuditLint captures status codes, canonicals, robots directives, and internal links in one pass, so you have a complete snapshot to compare against later.

After Deployment: Verify the Changes

Once the release is live, crawl production again and check:

[ ] robots.txt matches the production version, not staging.
[ ] No important page has picked up noindex, via meta tag or header.
[ ] Important URLs return the expected status codes.
[ ] Error pages return a real 404 or 410, not a soft 404.
[ ] Canonical URLs still point to the correct pages.
[ ] Redirects work, especially for URLs affected by routing changes, and permanent moves use 301.
[ ] HTTP to HTTPS and trailing-slash behavior is consistent.
[ ] Titles, meta descriptions, and headings match the baseline or changed intentionally.
[ ] Structured data and hreflang tags are still present and valid.
[ ] Key content and internal links are in the server-rendered HTML, not only after JavaScript runs.
[ ] Sitemap URLs match the live site.
[ ] Every unexpected difference is investigated before the release is closed.

A successful deployment is not just one that returns HTTP 200. Important pages must keep the technical signals that make them crawlable, indexable, and understandable to search engines.

Automate the Smoke Test

You don't need a full crawler to catch the worst regressions. A short script against a list of important URLs covers a lot:

#!/usr/bin/env bash
# seo-smoke-check.sh: post-deploy check for key URLs
# Usage: ./seo-smoke-check.sh https://example.com important-urls.txt

BASE="$1"
URLS="$2"

echo "== robots.txt =="
curl -s "$BASE/robots.txt" | grep -i "disallow: /$" && echo "WARNING: site-wide Disallow found"

echo "== Pages =="
while read -r path; do
  url="$BASE$path"
  status=$(curl -s -o /tmp/page.html -w "%{http_code}" "$url")
  header_robots=$(curl -sI "$url" | grep -i "^x-robots-tag" | tr -d '\r')
  meta_noindex=$(grep -io '<meta[^>]*noindex[^>]*>' /tmp/page.html)
  canonical=$(grep -o '<link[^>]*rel="canonical"[^>]*>' /tmp/page.html | grep -o 'href="[^"]*"')
  title=$(grep -o '<title>[^<]*</title>' /tmp/page.html)

  echo "$status | $path | $canonical | $title"
  [ -n "$header_robots" ] && echo "  header: $header_robots"
  [ -n "$meta_noindex" ] && echo "  WARNING: meta noindex found"
done < "$URLS"

Store the output from your last good release and diff the new run against it. Then wire it into your pipeline as a post-deploy job:

# .github/workflows/seo-check.yml
name: Post-deploy SEO check
on:
  deployment_status:
jobs:
  seo-check:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run SEO smoke check
        run: |
          ./seo-smoke-check.sh https://example.com important-urls.txt > current.txt
          diff baseline.txt current.txt

A non-zero diff fails the job, so someone has to look at what changed before moving on.

Compare the Results, Not Just the Error Count

A post-deployment crawl may report fewer issues without proving the release succeeded. Pages may have dropped out of the crawl entirely because links broke or a section became blocked. Fewer pages crawled can mean fewer errors reported.

Compare actual URLs and elements between crawls, and separate intentional changes from regressions:

Check	Before	After	Action
robots.txt	Allows crawling	`Disallow: /`	Roll back immediately
Product page	HTTP 200	HTTP 200	Verify content and metadata
Canonical URL	Self-referencing	Points elsewhere	Investigate
Internal links	No broken links	New 404 links	Fix source links or add redirects
Robots directive	Indexable	`noindex`	Confirm intent
Structured data	Product schema	Missing	Check template changes
Page title	Present	Missing	Check template changes

For full-site comparisons, a crawler that keeps crawl history makes this much easier. SiteAuditLint compares crawls over time instead of treating each one as an isolated report, which fits this before-and-after workflow directly.

Decide What Blocks a Release

Agree on rollback criteria before you need them. A reasonable starting point:

Roll back immediately: site-wide Disallow, noindex on key templates, or important pages returning 5xx or 404.
Fix within hours: missing canonicals, broken redirects for high-traffic URLs, missing structured data on product or article templates.
Fix in the next sprint: isolated broken links, title or description changes that weren't intended.

After the release, keep an eye on Google Search Console. The URL Inspection tool confirms how Google sees a specific page, and the Pages report shows indexing drops that a crawl alone might miss.

Make It Part of the Release Workflow

The cheapest time to catch a technical SEO regression is before it affects search visibility. Establish a baseline, crawl after deploying, compare the results, and treat unexpected differences as bugs.

Automated checks handle the repeatable validations. Crawl comparisons catch the broader site-level changes. Together they cover the technical signals your unit tests, integration tests, and visual QA were never designed to check.

The goal is simple: know what changed, decide whether it was intentional, and make sure the release didn't introduce avoidable SEO problems.

What's the worst SEO regression you've seen ship to production? Share it in the comments.

Written by [Your Name], technical SEO specialist at Remar Digital, where we help teams build SEO checks into their development and release workflows. Disclosure: I'm affiliated with SiteAuditLint.``

DEV Community: Rem Barquilla