The most expensive SEO defects are not the ones an audit finds; they are the ones a deploy introduces. A staging flag that ships to production, a layout rewrite that loses the canonical tag, a redirect rule that starts matching too much. They pass code review because nobody reviews for search, and they show up weeks later as a drop that looks like an update.
The defence is a diff. Crawl the site before the release and after it, compare the fields that matter for search per URL, and read the difference the way you would read a test failure.
The steps
- Decide which fields countStatus code, canonical URL, robots directives on the page and in the header, title, meta description, H1, and the count of internal links out. That set is the surface hash: if none of those changed, the page did not change in any way search cares about, whatever else the deploy did.
- Crawl a fixed sample before the releaseNot the whole site — a few hundred URLs chosen to cover every template: one of each page type, the home page, a paginated page, a filtered listing. The sample matters more than the size. Save the fields per URL.
- Crawl the same sample after, and diffPer URL, per field. The interesting lines are the ones where a field changed and the release notes do not mention it. A canonical that now points at a different URL, a noindex that appeared, a title that became the site name on a whole template.
- Treat a template-wide change as a release blockerOne page changing is a content edit. Every page of a type changing the same way is a template, and if nobody meant it, it is a regression. This is the same grouping that turns findings into causes, used as a gate rather than a report.
- Automate it against the deploy, not the calendarA monthly crawl catches the regression up to a month late. A crawl triggered by the deploy — a webhook from the release pipeline — catches it the same hour. If a deploy hook is not available, a daily crawl of the sample is the fallback, and it is far better than the monthly audit.
The same diff, read the other way
The crawl that detects a regression also detects a fix. When the diff shows a defect gone from every page in a group and the release notes say the developer fixed it, that is the fix landing, timestamped, without anyone marking a ticket done. That is the moment to freeze a control set and start the measurement window, and it is the reason the detection and the measurement belong in the same system.
Whether the developer actually shipped the fix and whether they shipped something else by accident are one question with two answers, and the same crawl gives both.
Questions people ask
Can I do this in CI instead of with a crawler?
Partly. A test that renders each template and asserts on the canonical and robots meta catches the most common regressions before deploy, and it is worth writing. It cannot see redirect rules, CDN headers, or robots.txt, all of which live outside the application, so a crawl of the deployed site is still the check that sees what Google sees.
How does Rankelle do this?
Every site has a deploy webhook URL. Hit it from the release pipeline and the sentinel re-checks the watched pages within the hour, diffing the same surface hash described above. A defect appearing on a template is reported as a new cause; a defect disappearing is recorded as landed and the measurement starts. How the pieces fit is the longer description.
Try it on your own site, free
The whole audit of every website you add, no card and no expiry. Pay only when you want the proof.