Green build, broken SEO: what a deploy can break that your checks never see

The deploy went out on Friday. The build was green, the tests passed, the preview looked right, and the site works for everyone who opens it. Three weeks later someone notices that sign-ups from Google have dropped by a third.

The cause is usually small: one line in a layout, a setting copied from staging, a redirect added in a hurry. Nothing a visitor would notice, and nothing a build or a test checks, because none of them look at the page the way a search engine does.

This article lists the changes we see most often, how to recognise each one, and a short routine for after every production deploy.

Why tests don’t catch it #

Tests check that the page works: the button submits, the price adds up, the page returns 200. Search engines read different things, mostly in the <head> and in the HTML the server sends before any JavaScript runs. A page can work perfectly for people and still tell Google not to index it.

And Google is slow to show you. A page dropped from the index loses its traffic over days, and Search Console reports it a few days later still. By then the change is buried under other deploys.

Eight changes that break search without breaking the site #

1. A noindex that came from staging #

The most expensive single line in SEO:

<meta name="robots" content="noindex">

It usually arrives from a staging setting that also runs in production, a component that adds it when an environment variable is missing, or a template copied from a private page. The same instruction can also come as an HTTP header, X-Robots-Tag: noindex, which you won’t see in the page source at all.

2. robots.txt blocking more than intended #

A Disallow: / meant for staging, or a new rule that covers more paths than planned. Two details make this worse than it looks: a page blocked in robots.txt can’t be crawled, so Google never sees its content or its noindex; and Google doesn’t support noindex inside robots.txt, so that line does nothing.

3. A canonical that points somewhere else #

The canonical tag tells Google which address is the main one. After a deploy it can start pointing to the home page on every page, to a preview address like my-project-git-main-team.vercel.app, or to http:// instead of https://. Google treats the canonical as a strong hint, and a wrong one can move your rankings to an address nobody visits.

4. Content that only appears after JavaScript runs #

A refactor moves the product list or the article text from the server to the browser: the page looks identical, but the HTML the server sends is now almost empty. Google does run JavaScript, but later and not always completely. Text in the server HTML is the safe choice for anything you want found.

5. Redirects and status codes #

A page that used to answer 200 now answers 404, or redirects to the home page, or goes through three redirects before it arrives. A permanent move should be one 301 or 308 straight to the final address. Errors of the 5xx type that last for days make Google crawl less and eventually drop pages.

6. A sitemap that lost pages #

A new route or a CMS change produces a sitemap without some of the URLs that bring traffic, or with addresses that now redirect. The sitemap is not a ranking factor, but it is how Google learns about pages quickly and how you see indexing problems per page in Search Console.

7. Titles, descriptions and headings replaced by defaults #

A shared layout starts overriding page titles with the site name, or every page gets the same description. Not a disaster on one page; real damage when it happens to the 20 pages that bring most of your visits.

8. Language versions that stopped pointing at each other #

On a site in several languages, hreflang links tell Google which version to show to whom. They have to be reciprocal: if the Japanese page points to the English one, the English page must point back. A deploy that changes URLs in one language breaks the pair, and Google may show the wrong language in search results.

How to check a page in two minutes #

You don’t need a tool for a spot check. In a terminal:

# Status code, redirects and the X-Robots-Tag header
curl -sIL https://www.example.com/pricing | grep -iE "^HTTP|^location|x-robots-tag"

# robots meta tag and canonical in the server HTML
curl -sL https://www.example.com/pricing | grep -ioE '<meta[^>]+robots[^>]*>|<link[^>]+canonical[^>]*>'

# robots.txt as it is now
curl -s https://www.example.com/robots.txt

To see whether the main content is in the server HTML, open the page with View page source (not the inspector, which shows the page after JavaScript) and search for a sentence from the body. In Search Console, the URL Inspection tool shows the page as Google fetched and rendered it, and whether it is allowed to be indexed.

A routine for every production deploy #

Checking every page by hand doesn’t scale, so check the pages that matter:

1. List your top pages. In Search Console, open Performance, sort pages by clicks for the last three months, and take the top 10 to 20. Those pages are most of your search traffic.
2. After each deploy, run the checks above on those pages: status, noindex in the tag and the header, canonical, title, and a sentence of body text in the server HTML.
3. Look at robots.txt and the sitemap whenever routing, the CMS or the framework changed.
4. Write down what “normal” looks like for each page (status 200, canonical to itself, title), so a change stands out.
5. Keep an eye on Search Console for the next week. The Pages report and the clicks of your top pages will show the problems that slipped through.

Most of this list is also part of good monthly website maintenance. The difference is timing: a check right after the deploy finds the problem while it is still one commit to revert, not three weeks of lost visits.

We built Hawk Delta to do exactly this for the Vercel sites we maintain: after each production deploy it compares the important pages with the last good version and emails what broke, how much search traffic is at stake and how to fix it. It is now in a free private beta.