A page holding first position disappears overnight. Looking closer, eleven other phrases from the same cluster went dark at the exact same moment. No penalty, no technical error, no algorithm update, and every audit tool still reporting one hundred percent health.
They were right. The problem was not in our pages, it was in what Google had time to read. It took us a day to work it out, and what we found probably applies to your site too.
Here is the full investigation, with the real numbers, and the method to check yours in ten minutes.
Key takeaways
Google was spending only 8% of its crawling on our pages, with everything else going to technical files.
The cause was an identifier automatically appended to the site's files, changing on every deployment.
This setting is enabled by default on a large share of modern websites. Nobody requests it, nobody sees it.
Direct consequence: one of our pages had not been re-read in eighteen days.
Checking takes ten minutes and requires no technical skill.
The symptom, pages going dark without warning
What we saw
One of our pages had held first position on a specific phrase for several weeks. One morning it was nowhere to be found. Digging further, we realised eleven phrases from the same cluster had disappeared together, at the same moment, despite occupying very different positions the day before.
A simultaneous disappearance across an entire cluster is never chance. It is a signal, and we needed to work out which one.
The checks that came back clean
The first instinct is to look for a fault in the page itself, so we took it apart.
It responded normally, in under a second. It explicitly allowed indexing, and its canonical tag pointed to itself, correctly formed. It carried 2,873 words of original content, organised into sections. Google Search Console stated without any ambiguity that this URL was on Google and the page was indexed.
Everything was correct, and yet it no longer appeared in results.
The reasoning error to avoid
At this point the temptation to change the page is strong: rewrite the title, add content, restructure the sections, redo the internal linking. That is the classic mistake, and the most expensive one over time. You repair something that was not broken, you lose what was working along the way, and the real problem sits untouched while you keep busy.
Before changing anything, you need to know what you are looking for.
Rule out the outside world before blaming your own site
Did Google move?
A ranking drop often coincides with turbulence at Google, and public search volatility indicators exist, updated daily country by country. That is the first thing to check, before even looking at your own site.
On the day of our drop, France showed 0.5 out of 10. The only spike in the previous thirty days went back two weeks, at 3.1, a level the tool itself describes as normal.
What that rules out
Dead calm during a drop concentrated on a single cluster closes the algorithm hypothesis. Had Google changed something in its ranking, the effect would have been broader and visible elsewhere on the site, not confined to eleven related phrases.
The problem was ours, then. The question was where, and that is where the investigation really started.
The answer sat in a report nobody opens
Where to find it
Search Console holds a report filed away in the settings, apart from the dashboards everyone checks, called crawl stats. It does not tell you what Google indexes, nor how your pages rank. It tells you what Google's robot actually downloads from your site, file by file, day after day.
The distinction sounds minor and yet it explained everything.
What it showed
| File type downloaded | Share of total |
|---|---|
| JavaScript | 60% |
| Other files | 22% |
| HTML pages | 8% |
| CSS | 6% |
| Images | 2% |
Eight percent.
Across 14,500 requests in three months, Google was spending only eight percent of its effort reading pages. Everything else went to the technical files that make the site run, the ones nobody ever reads and that carry no content to index.
Confirmation from a second angle
The same report offers a breakdown by robot type, and it tells exactly the same story in another form. Fifty-two percent of visits were plain resource loading, against thirty-eight percent of actual page reading.
Two independent measurements pointing at the same conclusion, that is what turned a hunch into a diagnosis.
What it means in days
The arithmetic is simple and it stings.
Fourteen thousand five hundred requests over ninety days works out at roughly one hundred and sixty-one per day. Eight percent of that in pages gives thirteen pages read daily, for a site that holds one hundred and four.
Google therefore needed eight days minimum to cover the whole site. In practice considerably more, since a search engine returns far more often to a homepage than to a deep page, which skews the distribution further.
We checked the missing page, and its last crawl went back eighteen days. Google had simply stopped following what happened on it.
The cause, thirty characters added automatically
What we found in the code
Every page on our site loads twenty-eight technical files. We listed them one by one, looking at the full addresses rather than the file names.
/_next/static/media/NeueMontreal_Bold.woff2?dpl=dpl_DgApsTYk8KqUwTBCUvUk1EovJQGY
/_next/static/chunks/1mfby909i8658.css?dpl=dpl_DgApsTYk8KqUwTBCUvUk1EovJQGYThat ?dpl= at the end of every address is a deployment identifier, and it changes each time the site goes live. Of the twenty-eight files, all twenty-eight carried it, font files included, even though those had not changed in months.
The same mechanism runs on most modern platforms, including automatically generated websites built by AI tools, which sit on the very same technical foundations.
Why that is a problem
An address that changes is, to Google, a new address. The fact that the file is rigorously identical to the previous one makes no difference at all, since the engine reasons on the address and not on the content.
On every deployment it discovered twenty-eight brand-new addresses per page. It downloaded them, processed them, remembered them, then started again in exactly the same way on the next release. On a site deployed several times a day, the cumulative effect becomes substantial within weeks.
The proof
It had been sitting in front of us for months, in the indexing report. One hundred and ninety-seven addresses filed as crawled, currently not indexed, a figure climbing steadily since the previous November.
We opened the list, and the first ten addresses carried ten different deployment identifiers. Google was holding the files from ten successive versions of the site and kept visiting every one of them, week after week.
Why the setting exists and why it stays invisible
The problem it solves is real
The parameter comes from a feature called skew protection, and it answers a legitimate need. When you update the site while a visitor has had a page open for a while, that visitor can end up on a hybrid version, half old and half new, and hit an error the moment they click. The identifier guarantees everyone stays on a consistent version until they reload.
So it is not a bad feature. It is a useful feature whose side effect on search nobody measured.
Three reasons you never notice it
First, it is enabled by default on every project created since late 2024. No decision was made, no box was ticked, it is simply there.
Second, it stays entirely invisible to visitors. The site works perfectly, performance is excellent, and no perceptible symptom gives it away.
Third, and most awkwardly, its effect on search is documented nowhere. Not in the platform's documentation, not in the best-practice guides circulating in the trade. The only place the mechanism is described is Google's own documentation, which covers the general principle without ever naming the tools that trigger it.
What Google says, precisely
The sentence that describes our case exactly
Search Central documentation covers this scenario word for word, in an article published in December 2024 about how crawling works:
"Use cache busting parameters with care: if the URLs of resources change, Google may need to crawl them again, even if their content hasn't changed. This will of course consume crawl budget."
Why standard cache settings are useless here
The same document notes something else, which explains why the problem escapes even competent technical teams. Google's rendering service keeps resources cached for up to thirty days, regardless of the caching instructions sent by the server.
Our files were nonetheless configured impeccably, with a one-year retention and the immutable flag, the one telling browsers the file will never change. To no effect whatsoever. Google applies its own rules, and a changing address stays a new address in its eyes, whatever instructions you send it elsewhere.
It is counter-intuitive, and that is precisely what makes this problem so hard to spot.
The trap you must not fall into
The plausible bad idea
Once the diagnosis is made, the instinctive reaction is to block robots from those technical files through robots.txt. The reasoning looks watertight: fewer files crawled, therefore more budget available for the pages that actually matter.
It is a very bad idea, and Google says so bluntly in the same documentation. Disallowing resource crawling generally causes problems, and if the rendering service cannot fetch a resource needed to display a page, Google Search may struggle to extract the content and rank the page at all.
What actually happens
Block those files and you do save crawl budget, while losing your pages in the process. Google can no longer reconstruct what the visitor sees on screen, so it can no longer judge the relevance of the content, so it stops ranking the page.
The cure kills the patient. We nearly did it, and it was rereading the documentation that stopped us in time.
The fix and what it changed
What we did
The answer was not to block anything, but to stop creating new addresses on every deployment. We disabled skew protection in the project settings, then put the site back online.
One toggle, one deployment, under two minutes of work.
The immediate check
Of the twenty-eight technical files on a page, not one still carried the parameter. No query string anywhere, the addresses were clean again.
File names remain identified by their content, which means an unchanged file keeps exactly the same address from one release to the next. Google therefore has nothing new to discover as long as the file itself has not moved.
The signal that looks like a problem and is not
Four days later, the number of 404 addresses rose in Search Console. A figure climbing in an error report is generally not good news, so we went to see what was happening.
The list held nothing but old technical files carrying that same parameter, from previous versions of the site, which genuinely stopped existing long ago.
That is the cleanup starting. Those addresses leave the crawled but not indexed status, where Google returns endlessly without ever doing anything with them, for the not found status, where it eventually abandons them for good. And since the parameter is no longer added to new files, the stock does not rebuild.
How long before the effect shows
It is worth being honest about timescales, because that is where many people give up. Crawl statistics are a ninety-day rolling average, so they move slowly by design, and a recent fix is mechanically diluted in three months of prior data.
The fast signals sit elsewhere. The last crawl date on your important pages reacts within days, as does the curve of addresses filed as crawled, currently not indexed. Those are the two indicators to watch during the first fortnight, not the overall average.
Check your own site in ten minutes
This investigation reproduces on any site, with no particular technical skill. Five steps, in this order. Google also publishes a full guide on crawl budget management, useful if you want to go further.
Step 1, the crawl split
Open Search Console, go to the Settings menu, then Crawl stats, and look at the table headed by file type.
If HTML pages drop below twenty percent, your budget is going elsewhere. Below ten percent the problem is serious and deserves attention straight away.
Step 2, confirmation by robot type
Stay in the same report and scroll down to the by Googlebot type section. If the page resource load line exceeds half the total, what you saw in the previous step is confirmed by a second measurement.
Step 3, the ghost address list
Move to the Indexing menu, then Pages, and open the crawled, currently not indexed reason to display the list of addresses concerned.
If you find technical paths, file names, folders with unreadable names, rather than real pages from your site, you have your culprit.
Step 4, the parameter in the code
Open any page on your site, view the source, and look at the files it calls. Check whether their names are followed by a question mark and a string of letters and numbers.
If so, redeploy the site and look again. If that string has changed while the file itself has not moved, you have exactly the same problem we had.
Step 5, your pages' freshness
Take a page that matters to your business, paste its address into Search Console's URL inspection tool, open the indexing detail and read the last crawl date.
If it goes back more than two weeks, Google is no longer following what you publish on that page, and anything you change there takes a considerable time to be taken into account.
What this story really says
A site with no defect can undermine itself
Our site reported one hundred percent health across every audit tool, zero errors and zero warnings. Those tools were not wrong either: in the sense they understand, there genuinely was nothing to flag.
The problem was not a defect. It was a perfectly legitimate setting, applied by default by a serious platform, whose side effect appears on no existing checklist. No tool looks for it because no tool knows it needs looking for.
The difference between a site that works and a site that is watched
A delivered site, however impeccably built, drifts over time. Platforms change their defaults without warning, tools change behaviour from one version to the next, search engines adjust their priorities. What was correct six months ago is not necessarily correct today, and nothing tells you so. That holds for crawl budget as much as for search in the age of generated answers, where the rules shifted without anyone being told.
No alert fires, no indicator turns red. You have to go and look yourself, regularly, in reports nobody opens spontaneously because they serve no purpose as long as everything is fine.
What we take from it
This failure cost us nothing but time, because we went and looked. A site with nobody opening those reports could lose its visibility for months without ever understanding why, diligently rewriting pages that had absolutely nothing wrong with them.
That is the part of the job nobody sees, the part nobody ever invoices explicitly, and it is the one that makes the difference over time.
Ran the five checks and something worries you?
Send us your site address. We'll look, and tell you what we see.
