--- title: "Brafton's accidental sitewide noindex: a six-week recovery" url: https://seomadman.com/studies/noindex-deploy-brafton-recovery-case-study section: studies published: 2026-09-25T00:00:00.000Z modified: 2026-09-25T00:00:00.000Z author: Adam Hafez topics: ["Indexing"] --- # Brafton's accidental sitewide noindex: a six-week recovery ## The short answer Brafton accidentally deployed a sitewide noindex tag in August 2019. Search traffic fell 33.2% in the first week. It recovered to baseline after six weeks, while some pages needed eight-plus weeks to re-index. Jeff Baker's account, published on Moz, found that pages regained their full visibility once indexed again. ## Key takeaways - A code sprint deployed on August 1, 2019 put a noindex, nofollow robots tag on every Brafton page, and the team noticed almost three days later. - Search traffic was down 33.2% one week after the fix, which Jeff Baker reports as the peak level of damage during the incident. - Search visibility returned to baseline after six weeks, and all pages were re-indexed after about eight to nine weeks. - Requesting indexing, resubmitting sitemaps and updating content did not force re-crawls of about 150 stubborn pages, and one product page stayed out until October 1. - Pages that were indexed again recovered their original search visibility, so the slow part of recovery was re-indexing, not ranking. Jeff Baker, a director of digital marketing strategy at Brafton, published a first-person account on the Moz blog of a mistake every SEO fears. A deployment put a `noindex` robots tag on every page of brafton.com. This write-up summarises his numbers; every figure below comes from that post. ## What caused the sitewide noindex? A developer sprint deployed on the evening of Thursday, August 1, 2019 accidentally pushed `meta name="robots" content="noindex, nofollow"` live on every page. Baker spotted the ranking drop on Sunday, August 4, almost three days later. Search Console flagged "noindex detected in robots meta tag", and the developer rolled the update back. Baker also deleted the old sitemap, built a new one and re-uploaded it, and manually requested indexing for most core product landing pages. ## How did he diagnose it? His sequence is a useful triage order. Rankings had vanished in his rank tracker, and Google Analytics showed a matching traffic drop, so the data was real. He then checked whether the date lined up with a confirmed algorithm update; it did not. Complete disappearances rather than fluctuations pointed him to a technical cause, and a Google search for the missing pages confirmed they were gone from the index. Search Console was little help in sizing the damage. Baker notes it only ever reported a maximum of 249 affected pages out of more than 8,000 indexed, which he calls impossible given that search presence was still down by a third a week after the fix. Google would have had to crawl every page within three days to see the tag everywhere, so the real number of de-indexed pages remains unknown. ## How much traffic did the site lose? Baker measured from August 2. After the first week, about 33.2% of search traffic was gone, which he calls the peak of the damage. His weekly headings report drops of 23% at two weeks, 13% at three and 9% at four, then 10.4% at five; the two-week paragraph itself says the site was still 8% down, so that one figure is inconsistent in the source. At six weeks traffic stood 5.3% above baseline. He estimates the incident purged about 12% of all organic traffic overall, with commercial conversions falling in proportion, even though conversion rates rose. ## What slowed the re-indexing? Resubmitting sitemaps and requesting indexing did not speed things up for a stubborn group of about 150 pages, which URL Inspection reported as indexable but which were not crawled. For one high-value product page he tried inspecting and requesting indexing 15 times, plus republishing with updated dates and content, and it stayed out of the index until October 1. Search Console's validation feature, started on August 26, recrawled roughly 10 pages a week in his experience. He adds that the six-week recovery was partly flattering: some content overperformed and masked pages that were still missing. This matches how Google documents `noindex`. Its [noindex guide](https://developers.google.com/search/docs/crawling-indexing/block-indexing) says Googlebot has to crawl a page to see the rule, that it may take months for Googlebot to revisit a page depending on its importance, and that the URL Inspection tool and Page indexing report are the places to check what Google extracted. ## What should you take from it? Baker's conclusion is that once pages came back they were fully restored, so the bottleneck was re-indexing, not ranking. Search visibility returned to baseline after six weeks, and all pages were re-indexed after about eight to nine weeks. The practical lesson is prevention: check robots directives on the rendered output of every release, because getting back into the index is slow and Google controls the clock. A pre-release check can be small. Compare the robots meta tag on a handful of key templates against what you intend, using the [meta robots tag builder](/tools/meta-robots-tag-builder) as a reference, and confirm no `X-Robots-Tag` header slipped in with the [X-Robots-Tag header validator](/tools/x-robots-tag-header-validator), since Google honours the header as well as the tag. If you were considering `noindex` as a crawl budget lever, [it does not work that way](/research/noindex-crawl-budget-reality) either. ## Sources 1. [This Is What Happens When You Accidentally De-Index Your Site from Google](https://moz.com/blog/accidentally-deindex-your-site) - Moz Blog, Jeff Baker of Brafton (primary) 2. [Block Search indexing with noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing) - Google Search Central (primary)