Imagine having a page that ranks sixth in Google, attracts around 80 clicks a day and has no obvious technical problems. Then, within three days, its search impressions fall to zero.
The website owner had checked the usual suspects. There was no manual action, no security warning, no noindex tag and no robots.txt block. Google’s live URL test worked, the sitemap was accessible, and the page contained around 4,000 words.
Yet Google Search Console eventually reported the page as Crawled – currently not indexed.
The problem extended beyond one page. The number of indexed pages across the website fell from 152 to just 16.
This case shows why a successful technical check does not guarantee that Google will keep a page in its index. It also raises an important question: could slow server responses, problems displaying page content or a wider assessment of the website explain what happened?
This guide walks through the evidence, explains what the status means and sets out a practical plan for SEO, content, marketing and development teams.
1. Crawled – Currently Not Indexed: Why a Top-10, High Traffic Page Vanished in Three Days – What Happened?
The case: a page ranked sixth, then lost its search impressions
The website was a government-exam preparation site with around 150 pages. Its main page listed mock tests for a national staff selection exam.
The page had performed well for several weeks before disappearing from the search results.
Here is the timeline, based on the information shared by the owner.
| Period | What happened |
|---|---|
| From around 5 July 2026 | The mock tests page grew to more than 2,000 impressions and around 80 clicks a day. Its average position was 6.6, with 55,800 impressions and 1,760 clicks over three months. |
| 12–15 August | The page’s impressions fell to zero. |
| 13–14 August | Average response time in Google Search Console’s Crawl Stats report rose to 6.2 seconds and 4.6 seconds, compared with the usual 0.4 seconds. |
| 18–21 August | Google’s August 2026 spam update rolled out, after the page’s impressions had already disappeared. |
| Mid-August to 22 September | The number of indexed pages across the website fell from 152 to 16. |
| Early October | The page had received no impressions for seven weeks and was reported as Crawled – currently not indexed. |
The owner had already carried out several checks.
- There was no manual action or security issue in Search Console.
- URL Inspection showed that Googlebot had crawled the page successfully. The last recorded crawl was 4 October.
- Crawling was allowed, indexing was permitted and the user’s chosen canonical matched Google’s choice.
- There was no
noindextag or robots.txt block. - The sitemap was valid and Google could fetch it.
- The live test showed the page as users would normally see it.
- The page was rendered on the server and contained around 4,000 words.
- Google’s Search Status Dashboard showed no incident during the initial drop between 12 and 15 August.
- The Crawl Stats report did not show an unusually high rate of failed connections.
The owner was left with two questions: why would Google stop indexing a page that had performed so well, and what else should be checked when the usual tests show no problems?
What does ‘Crawled – currently not indexed’ mean?
Google uses this status when it has crawled a page but has not included it in its index. Its guidance says the page may or may not be indexed in the future.
In plain English, Google was able to fetch the page but did not keep it in the index.
That is different from a page that Google has not discovered, or one that it cannot access because of a technical problem.
Google can stop indexing a page that previously ranked well without issuing a manual action or reporting a technical error.
The page’s previous traffic and its 4,000 words did not guarantee that Google would continue to index it.
The advice was to compare the pages that had disappeared with the 16 that remained indexed. The owner was encouraged to look for similar content, repeated page templates and whether each page offered something useful that could not easily be found elsewhere.
A page can be accessible to Google but fail to display properly when Google renders it.
Google first fetches the page’s HTML and then uses a browser-based rendering process to process it. If important content fails to load, Google may not see the same page as a visitor.
Why did all the usual technical checks pass?
The important distinction is that most of these checks tell you whether Google can access a page. They do not explain why Google decides to include or exclude it from search results.
Google’s URL Inspection documentation explains that the live test does not assess content quality, does not establish the final canonical decision and cannot confirm that a page currently reported as Crawled – currently not indexed will be indexed.
A successful live test means Google can fetch the page at the time of the test. It does not guarantee that the page will be indexed.
| Check | What it tells you | What it cannot tell you |
|---|---|---|
| Manual actions and security reports | No manual action or security problem has been reported | Whether Google’s automated systems have decided not to index the page |
| URL Inspection | Whether Google has crawled the page and whether indexing is allowed | Why Google chose not to index it |
| Live URL test | Whether Google can fetch and render the page now | Whether the page rendered correctly during the original incident, or whether its content is worth indexing |
| Search Status Dashboard | Whether Google has announced a service incident | Whether an unannounced ranking or indexing change affected the page |
| Crawl Stats | Whether Google is encountering connection failures and how quickly the server responds | Whether scripts, styles or other resources failed while Google was rendering the page |
The next step is therefore to look beyond the green ticks. You need to understand what Google actually saw, whether the server was working properly and why other pages on the same website were also removed from the index.
2. Why Does This Matter? Crawled – Currently Not Indexed: Why a Top-10, High Traffic Page Vanished in Three Days
The case shows that a page can lose its search visibility even when Search Console does not identify a clear technical fault.
It also shows why the problem may be bigger than one URL. Five details stand out.
1. The problem affected the wider website
The mock tests page did not disappear in isolation.
The number of indexed pages fell from 152 to 16 in about five weeks. That means 136 pages disappeared from the index, a reduction of around 89%.
When nearly nine out of ten pages are no longer indexed, rewriting one article is unlikely to solve the entire problem.
Google may have reassessed a particular group of pages or the website more widely. The evidence does not tell us which explanation is correct, but the scale of the decline means it needs to be investigated.
We saw a similar sudden change affecting a group of pages in our article about templated pages disappearing from Google’s index.
2. The drop happened alongside a major slowdown
The website’s two slowest days in Crawl Stats were 13 and 14 August. These dates fell within the period when impressions dropped to zero.
Average response time rose to 6.2 seconds on the first day and 4.6 seconds on the second, compared with the usual 0.4 seconds.
That is roughly 15 times the normal response time on the first day and more than 11 times on the second.
The owner treated this as a separate issue because the rate of failed connections remained acceptable. However, a slow response can still cause problems even when the request technically succeeds.
There are two reasons to investigate this slowdown.
A slow response can leave Google with an incomplete version of the page.
Google may receive the main HTML while scripts, stylesheets or data requests fail to finish loading.
For a mock tests page, this could mean Google sees the surrounding text but not the actual tests, answer explanations or score table.
The page may look fine to someone browsing it under normal conditions, while Google sees a less useful version during a period of high server load.
Slow responses can also reduce how much Google crawls.
Google’s crawl budget documentation explains that higher server response times can reduce the amount of crawling Google is able to carry out.
Gary Illyes has discussed how crawling capacity can be lost quickly and may take one to three weeks to recover. We cover this in more detail in our guide to Google’s crawling, indexing and serving timings.
Fewer successful recrawls can slow recovery after a problem has been fixed.
Neither explanation proves that the slowdown caused the indexing loss. The two events may have happened at the same time by coincidence.
However, a major response-time spike during a sudden, wider indexing decline should be investigated rather than dismissed.
3. The page gained visibility for several weeks before losing it
The page started gaining visibility in early July and had lost its impressions by mid-August.
That is roughly five to six weeks of improving performance followed by a rapid decline.
This resembles our experiment with 3,000 AI-generated articles, where search visibility improved for about five weeks before dropping sharply.
One possible explanation is that Google initially had limited information about the pages, then assessed them again as more data became available. Gary Illyes has shared timing data suggesting that Google may discover new URLs within around 20 hours and revisit known URLs on a cycle of roughly 30 days.
The timing in this case is consistent with a later reassessment, but it does not prove that Google followed a particular schedule or that a second assessment caused the decline.
The lesson is straightforward: a page that starts ranking well has not necessarily secured a lasting position.
Businesses should look beyond the first few weeks of growth and make sure the page continues to meet a clear user need.
4. More words do not necessarily make a better page
Someone looking for a mock test wants to take a test.
A page with 4,000 words may seem comprehensive, but if most of the text repeats exam information available elsewhere, the page may offer little that is different.
The situation becomes more concerning if the actual test is hidden behind a sign-up, app download or script that Google cannot process properly.
The most valuable part of the page may be the test itself, while Google can only see the surrounding explanation.
That is why the content needs to be assessed in terms of usefulness, not simply word count.
5. There is no appeal against an ordinary indexing decision
A manual action has a reconsideration process. An automated decision not to index a page does not.
You can request indexing through URL Inspection or use Validate fix in the Page indexing report, where applicable. These actions ask Google to crawl the URL again; they do not appeal the indexing decision.
Repeatedly requesting indexing is unlikely to solve the underlying problem if the page remains incomplete, slow or unhelpful.
The status rarely changes without a meaningful improvement.
The practical response is to investigate what Google sees, compare the affected pages with those that remain indexed, and make changes that genuinely improve the website.
What the evidence tells us
| What happened | What it suggests | What to investigate |
|---|---|---|
| Impressions disappeared within three days | A sudden change rather than a gradual decline | Whether other pages dropped during the same period |
| Indexed pages fell from 152 to 16 | The issue may affect a group of pages or the wider website | Which page types remained indexed and which disappeared |
| Response times rose to 6.2 and 4.6 seconds | Google may have encountered slow responses or incomplete page rendering | Server, CDN and resource-loading logs |
| The page gained visibility for weeks before disappearing | Early rankings did not guarantee continued indexing | Whether the page offered unique and useful information |
| The live URL test passed | Google could access the page at the time of the test | What Google rendered during the original incident |
3. Which Websites Are Most at Risk?
Any website can have pages move to Crawled – currently not indexed. However, a sudden, wider decline after a period of rapid growth may be especially damaging for certain types of business.
Education and exam preparation websites
Exam preparation sites often publish mock tests, past papers, syllabus information and cut-off score pages.
Many websites cover the same exams and publish very similar information. If one page offers little beyond what is already available, Google has many alternatives.
Pages are more likely to offer a clear reason to stay indexed when they include original practice tests, their own performance data, expert explanations or useful features that competitors cannot easily copy.
Tools, calculators and quizzes
Interactive pages can provide substantial value, but the main feature needs to work for users and be available to Google’s rendering systems.
If a calculator or quiz depends on scripts that fail to load, needs a login before any useful information appears, or is wrapped in large amounts of generic text, Google may not see the page’s main purpose.
Small websites with templated pages
A common assumption is that indexing problems mainly affect large websites with millions of URLs.
This case involved a website with around 150 pages, yet the number of indexed pages fell by about 89%.
When many URLs use the same template, a problem affecting that template can have a wide impact, even on a relatively small website.
New and fast-growing websites
Pages that gain visibility quickly on a relatively new website may still be assessed again as Google gathers more information.
Early clicks and rankings are encouraging, but they do not guarantee continued inclusion in the index.
Businesses should review whether their pages remain useful, accurate and distinct after the initial period of growth.
Websites on shared or underpowered hosting
Slow server responses may coincide with an indexing decline, particularly during periods of high traffic, scheduled jobs or hosting problems.
The slowdown may not be the cause of the indexing issue, but it can make diagnosis and recovery harder.
E-commerce websites and marketplaces
Product category pages, filtered listings and other templated pages can share much of their content.
At larger scale, this can create thousands of pages that offer little information beyond the products they list.
Retailers should make sure each important page has a clear purpose and that Google can access the products and information that give it value.
Publishers and affiliate websites
Articles that repeat information already available from stronger sources may struggle to justify a place in the index.
The same applies to comparison pages that provide little original analysis or useful advice.
The businesses in a stronger position are those whose pages offer something visitors cannot easily get elsewhere, while keeping their websites fast enough for Google to access the content properly.
4. What Should Businesses Do?
Treat Crawled – currently not indexed on an important page as a problem to investigate first, rather than immediately assuming that the content needs rewriting.
Start by checking how widely the issue has spread. Then investigate page rendering and server performance, compare affected pages with those that remain indexed, and improve the content or technical setup where needed.
The following is the process we would use to investigate a case like this.
Step 1: Find out how much of the website has been affected
Timing: Day 1
Start with the Page indexing report in Google Search Console.
1. Look at the trend, not just the status.
Record when the number of indexed pages started falling and which reasons for non-indexing increased. In this case, the number of indexed pages fell from 152 to 16 while Crawled – currently not indexed became a concern.
2. Identify the pages that remained indexed.
Export the indexed and non-indexed pages. Label them by type, such as homepage, test page, article, category or interactive tool.
3. Put all the dates on one timeline.
Include the loss of impressions, the change in indexed page counts, Crawl Stats response times, website releases, hosting changes and any confirmed Google updates.
In this case, the slowdown on 13 and 14 August happened during the three-day drop. The August spam update began afterwards.
If only one page has disappeared, the cause may be specific to that page. If most of the website has been affected, investigate patterns across the wider site or across particular templates.
Step 2: Check what Google actually rendered
Timing: Days 1–2
A page can be available to Google without all its important content appearing in the rendered version.
This is a technical possibility, so check the rendered page instead of relying only on how it looks in a normal browser.
1. Run the live URL test.
In Search Console, open URL Inspection, select Test live URL and then View tested page.
Check the screenshot. Is the main content visible? For a mock tests page, can Google see the tests or only the text describing them?
2. Review the page resources and errors.
Open More info in the tested-page view. Look for resources that failed to load and JavaScript errors that may explain why some content is missing.
3. Compare Google’s rendered HTML with the browser version.
Copy the HTML from the tested page in Search Console.
Then open your own website in Chrome, open Developer Tools, select the Elements panel, right-click the <html> element and choose Copy outerHTML. Save the two versions as separate files.
This gives you a way to compare the HTML Google rendered with the page visitors see in their browser.
4. Use the comparison script below.
The developer toolkit at the end of this article compares the files and identifies missing headings, text, tables, forms and other elements.
A live test shows how Google renders the page today, not how it rendered it during the original incident.
If today’s version looks complete, investigate what was different during the slowdown. Data requests, test widgets and tables loaded through scripts may work under normal conditions but time out when the server is under pressure.
Step 3: Investigate the server slowdown
Timing: Days 1–3
A response time that rises from 0.4 seconds to more than six seconds is worth investigating even if most requests technically succeed.
Ask the development or hosting team to review server and content delivery network (CDN) logs around the dates of the decline.
The investigation should include:
- Verified Googlebot requests, rather than requests identified only by their user-agent string.
- Response times and status codes for the main HTML page.
- Timeouts or failures affecting scripts, stylesheets, images and API calls.
- Traffic spikes, scheduled backups, database locks and recent plugin or platform changes.
- Requests that were closed before the server finished responding.
Our guide to HTTP 499 responses explains how to investigate requests that are abandoned before the response is complete.
Do not focus only on fixing the symptom. If the main content is loaded by a script, consider whether it can be included in the server’s HTML response instead.
Depending on what the logs show, the solution may involve improving caching, adding CDN capacity, reviewing database performance or changing how the page loads its data.
Set up monitoring for Googlebot response times as well as average visitor performance. The two can differ, and a normal average for human visitors may hide a problem affecting crawling.
Step 4: Compare the pages that disappeared with those that survived
Timing: Week 1
This is one of the most useful parts of the investigation.
Compare the affected pages with the 16 pages that remained indexed.
Select around ten affected pages and compare them with the surviving pages.
| What to compare | Questions to ask |
|---|---|
| Page type and template | Did one template remain indexed while another disappeared? |
| Purpose | Does the page provide a working test or tool, or does it mainly describe one? |
| Unique information | How much of the content also appears on other pages on the same site or on competing websites? |
| Overlap | Do several pages answer the same question using slightly different wording? |
| Signs that users value the page | Does it have relevant backlinks, direct or returning visitors, or evidence that people use its main feature? |
| Rendering | Does Google see the important content on both the affected pages and those that remained indexed? |
The comparison can help you distinguish between a technical issue affecting a group of pages and a content problem involving pages that are too similar or offer little unique value.
Our guide to templated pages disappearing from the index includes a similarity audit that can help compare affected and surviving pages.
Step 5: Rebuild the page around what visitors actually need
Timing: Weeks 2–6
For a mock tests page, the most important thing is the tests themselves, not how much text surrounds them.
Here are five ways to improve a page of this type.
Make the tests available in the page.
Where possible, include a full test or a substantial set of sample questions and answers that visitors can access without downloading an app, creating an account or relying on a script that may fail.
If a login is essential for the full test, consider offering useful sample questions before registration.
Include data only your website can provide.
If your site runs the tests, you may have useful data about the number of attempts, score distributions, average scores by section and how practice results compare with published cut-off scores.
Make sure the figures are accurate, current and explained clearly. This information can give the page value beyond what a competitor can copy from a general exam guide.
Remove generic text that does not help the visitor.
If 4,000 words mainly repeat the syllabus and exam format available on other websites, reduce them to the information candidates need to choose a test and understand its results.
Link to a single, detailed guide for general exam information instead of repeating the same explanation on every page.
Explain who creates and checks the tests.
Name the subject experts who prepare or review the questions, where appropriate, and give a truthful account of their relevant experience.
Include the date of the latest review so visitors can see whether the information relates to the current exam cycle.
Keep the page up to date.
Exam dates, formats, entry requirements and cut-off scores can change. Check important facts against reliable sources and update the page when the information changes.
The aim is to make the page genuinely useful to candidates, not simply longer than competing pages.
Step 6: Reduce and combine the rest of the website
Timing: Weeks 2–6
If 136 pages disappeared from the index, the wider page structure needs to be reviewed as well.
Some pages may still be useful but need work. Others may repeat the same information or have no clear reason to exist as separate URLs.
The appropriate actions include:
- Combine overlapping pages. Bring the useful information into one stronger page and redirect the old URLs to it when it is a suitable replacement.
- Remove pages that add nothing. Thin tag pages, near-identical test descriptions and empty archives may not need to remain on the website.
- Use noindex where appropriate. If a page must stay available to visitors but should not appear in search results, a
noindexdirective may be suitable. Google must be able to crawl the page to read it. - Update internal links. Make sure navigation, homepage links and related-content sections point to the pages you want visitors and Google to find.
- Clean up the XML sitemap. Include only the URLs you want Google to consider indexing, and keep
lastmoddates accurate.
Do not automatically delete every page that has not received impressions. Consider whether it serves users through other channels or provides a function that is not captured by Search Console.
Step 7: Ask Google to crawl the improved pages again
Timing: After the changes are complete
Once the important content and technical issues have been addressed, encourage Google to revisit the affected pages.
1. Request indexing for important pages.
Use URL Inspection for the key URLs you have improved. There are limits to how often you can submit requests, so focus on the pages that matter most.
2. Submit the updated sitemap.
Make sure the sitemap contains the pages you want indexed and that it can be fetched successfully.
3. Use Validate fix where it is available and relevant.
In the Page indexing report, open Crawled – currently not indexed and select Validate fix if that option is available for the issue.
This asks Google to check the affected URLs again. It is not an appeal and does not guarantee that the pages will be indexed.
4. Allow time for Google to reassess the site.
Some pages may be indexed within days of being recrawled. A wider change affecting dozens or hundreds of pages can take weeks or months to resolve, and there is no guaranteed recovery timetable.
Repeatedly submitting the same URL does not force Google to index it.
Step 8: Monitor important pages before the next problem occurs
Once the changes are complete, set up monitoring so the team can spot another decline earlier.
Track the index status of key pages.
Identify your 20–50 most important URLs and check their status regularly. The URL Inspection API can help with checks, although its quotas and limitations mean it should be used within Google’s rules rather than treated as a way to force indexing.
Monitor Googlebot response times.
Set alerts for a major increase in the response times associated with verified Googlebot requests. Do not rely only on averages for human visitors.
Compare rendered pages after important releases.
Run a rendering comparison after changes to page templates, scripts or data loading, especially where those changes affect the main content.
Review pages that gain visibility quickly.
When an important page starts ranking well, check that it still offers something useful and that its content is accurate, complete and accessible. Review performance over a longer period rather than assuming the initial growth will continue.
Who needs to do what?
| Team | Responsibilities | What completion looks like |
|---|---|---|
| SEO | Map the drop, compare affected and surviving pages, manage indexing requests and monitor key URLs | The timeline and comparison are agreed, and regular index checks are running |
| Development | Check rendering, analyse logs, fix slow responses and make sure key content is available in the HTML | Google can see the main content, response times have returned to normal and alerts are in place |
| Content | Rebuild important pages around real tests and original information, remove unnecessary text and combine overlapping pages | Every retained page has a clear purpose and useful information |
| Product | Make sample tests accessible and provide accurate statistics where available | Visitors can use the main feature without unnecessary barriers |
| Marketing | Update traffic forecasts, plan for a realistic recovery period and report index status regularly | Leadership has a realistic view of the impact and the expected next steps |
Developer Toolkit: Compare Google’s Rendered HTML with the Browser Version
This Python script compares two HTML files:
google.htmlcontains the HTML shown in Google Search Console’s rendered-page view.browser.htmlcontains the HTML copied from the website in Chrome.
It checks how many words from the browser version also appear in Google’s version. It also looks for missing text blocks, headings, tables, forms, buttons, links and other elements.
The script uses Python’s standard library and does not need additional packages.
How to get the two HTML files
Google’s version
In Search Console, open URL Inspection, select Test live URL, choose View tested page, then open the HTML tab. Copy the HTML and save it as google.html.
For an indexed page, you may also be able to use the stored crawled-page view.
The browser version
Open the same URL in Chrome. Wait until the page has finished loading, open Developer Tools and select the Elements panel.
Right-click the <html> element and choose Copy outerHTML. Save the result as browser.html.
Run the script with:
python3 render_diff.py google.html browser.htmlTo display more missing text blocks in the results, use:
python3 render_diff.py google.html browser.html --show 25How to interpret the results
The script reports the share of words visible in the browser version that also appear in Google’s rendered HTML.
If the figure is well below 90%, or important headings, tables or forms are missing, investigate why the two versions differ.
Possible causes include scripts or data calls that time out, resources blocked by robots.txt, content that appears only after a click, or features that require a login or cookie interaction.
A low score does not automatically mean the page is broken. The tool is designed to identify differences worth investigating.
What happened when we tested the script?
We tested the script using a sample mock tests page where the test list, start form and score table loaded through a script.
We compared it with a version of the page where that script had failed for Google’s rendered view.
The script reported that only 46% of the words visible to visitors were present in Google’s version. It identified eight missing text blocks, including the “Take a free full-length test” heading and the score information, and flagged the missing table, form and button.
When we tested two identical HTML files, the script reported no differences.
Testing also revealed a limitation with unclosed paragraph tags, which are common in real-world HTML. The script was updated to handle those cases.
These results show how a simple comparison can help developers identify content that visitors can see but Google may be missing.
The Python script
Save the following code as render_diff.py.
#!/usr/bin/env python3
"""
render_diff.py - Szymaniak Digital
Compare the HTML rendered for Google with the HTML seen in a browser.
Reports:
- Word coverage: the share of browser words also present for Google.
- Text blocks visible to visitors but missing from Google's version.
- Differences in important page elements.
- Link targets found only in the browser version.
How to get the files:
1. Google Search Console > URL Inspection > Test live URL >
View tested page > HTML tab. Save as google.html.
2. Chrome > DevTools > Elements > right-click <html> >
Copy > Copy outerHTML. Save as browser.html.
Usage:
python3 render_diff.py google.html browser.html [--show 15]
This is a comparison tool, not a Google indexing test. Differences need
manual review; some differences between the two files may be harmless.
"""
import re
import sys
import argparse
from html.parser import HTMLParser
SKIP = {"script", "style", "noscript", "template", "svg"}
BLOCKS = {
"h1", "h2", "h3", "h4", "p", "li", "td", "th",
"label", "button", "a", "figcaption", "dt", "dd",
}
VOID = {
"area", "base", "br", "col", "embed", "hr", "img",
"input", "link", "meta", "source", "track", "wbr",
}
class Doc(HTMLParser):
def __init__(self):
super().__init__(convert_charrefs=True)
self.words = []
self.blocks = []
self.counts = {}
self.links = set()
self.title = ""
self._skip = 0
self._open = []
self._in_title = False
def handle_starttag(self, tag, attrs):
attributes = dict(attrs)
self.counts[tag] = self.counts.get(tag, 0) + 1
if tag in SKIP:
self._skip += 1
if tag == "title":
self._in_title = True
if tag == "a" and attributes.get("href"):
self.links.add(attributes["href"].split("#")[0])
if tag in BLOCKS and tag not in VOID:
self._open.append([tag, []])
def handle_endtag(self, tag):
if tag in SKIP and self._skip:
self._skip -= 1
if tag == "title":
self._in_title = False
if tag in BLOCKS and any(
open_tag == tag for open_tag, _ in self._open
):
while self._open:
open_tag, parts = self._open.pop()
text = " ".join(" ".join(parts).split())
if self._open:
self._open[-1][1].append(text)
if text and open_tag != "a":
self.blocks.append((open_tag, text))
if open_tag == tag:
break
def close(self):
super().close()
# Capture blocks that were left unclosed, such as stray <p> tags.
while self._open:
tag, parts = self._open.pop()
text = " ".join(" ".join(parts).split())
if self._open:
self._open[-1][1].append(text)
if text and tag != "a":
self.blocks.append((tag, text))
def handle_data(self, data):
if self._skip:
return
if self._in_title:
self.title += data.strip()
return
self.words.extend(re.findall(r"\w+", data.lower()))
if self._open:
self._open[-1][1].append(data)
def load(path):
document = Doc()
with open(path, encoding="utf-8", errors="replace") as handle:
document.feed(handle.read())
document.close()
return document
def norm(text):
return " ".join(re.findall(r"\w+", text.lower()))
def main():
parser = argparse.ArgumentParser()
parser.add_argument("google")
parser.add_argument("browser")
parser.add_argument("--show", type=int, default=15)
args = parser.parse_args()
google = load(args.google)
browser = load(args.browser)
google_words = set(google.words)
covered = sum(
1 for word in browser.words if word in google_words
)
coverage = (
covered / len(browser.words)
if browser.words
else 1.0
)
google_text = " " + norm(
" ".join(text for _, text in google.blocks)
) + " "
missing = [
(tag, text)
for tag, text in browser.blocks
if len(norm(text).split()) >= 4
and " " + norm(text) + " " not in google_text
]
seen = set()
unique_missing = []
for tag, text in missing:
key = norm(text)
if key not in seen:
seen.add(key)
unique_missing.append((tag, text))
missing_words = sum(
len(norm(text).split())
for _, text in unique_missing
)
print(
f"Title Google: {google.title[:70]!r}\n"
f" Browser: {browser.title[:70]!r}"
)
print(
f"Words Google: {len(google.words):,} | "
f"Browser: {len(browser.words):,} | "
f"Browser words also present for Google: {coverage:.0%}"
)
print(
f"Text blocks {len(unique_missing)} blocks "
f"({missing_words:,} words) visible to users are missing "
f"from Google's rendered version"
)
print("Elements Google / Browser")
for tag in (
"h1", "h2", "h3", "table", "form", "input",
"button", "a", "img", "iframe",
):
google_count = google.counts.get(tag, 0)
browser_count = browser.counts.get(tag, 0)
if google_count or browser_count:
note = (
" <-- fewer for Google"
if google_count < browser_count
else ""
)
print(
f" {tag:<8} "
f"{google_count:>6} / {browser_count:<6}{note}"
)
browser_only_links = len(browser.links - google.links)
print(
f"Links {browser_only_links} link targets appear "
f"only in the browser version"
)
important_missing = any(
tag in ("h1", "h2", "td", "th", "label", "button")
for tag, _ in unique_missing
)
if coverage >= 0.90 and not important_missing:
verdict = "CHECK PASSED: Google saw substantially the same page"
else:
verdict = "INVESTIGATE: Google may have seen a weaker page"
print(f"Verdict {verdict}")
if unique_missing:
print(
f"\nFirst {min(args.show, len(unique_missing))} "
f"missing text blocks:"
)
for tag, text in unique_missing[:args.show]:
print(f" <{tag}> {text[:110]}")
if __name__ == "__main__":
sys.exit(main())5. What We’re Watching Next
Cases like this raise questions that Google’s existing reports do not fully answer for our new clients. These are the areas we will continue to follow.
Why Google decides not to index a page
Search Console tells website owners that a page has been crawled but not indexed. It does not provide a detailed explanation of the decision.
More specific information about whether the issue relates to duplication, content quality or rendering would help website owners spend less time guessing.
We have not seen evidence in this case that Google is about to provide that level of detail.
Whether slow responses lead to incomplete rendering more often
Google’s crawl budget guidance already explains that slow responses can reduce crawling.
We will continue to watch how often technical issues appear alongside wider indexing declines, particularly when important page content relies on scripts or external data requests.
That is a reason to monitor Googlebot’s experience separately from normal visitor performance.
Whether pages lose visibility after a few weeks of growth
The pattern in this case also resembles our test involving 3,000 AI-generated pages: initial growth followed by a sharp decline after several weeks.
We will continue comparing examples like these to understand whether this pattern occurs more often and how much it varies between industries and website types.
The timing alone does not establish what Google’s systems did, so we will distinguish observed changes from possible explanations.
Whether exam-preparation websites with real tools perform better
Exam preparation is a crowded market where many websites cover the same questions and exam information.
A website that offers working tests, original performance data and expert guidance gives visitors something more useful than a page that repeats general information.
We will be watching whether those features help important pages remain visible over time, while recognising that no single feature guarantees indexing.
Whether small websites continue to lose groups of pages at once
The loss of 136 out of 152 indexed pages shows that a website does not need millions of URLs to experience a large indexing decline.
We will continue to look for cases where several pages disappear together and investigate whether the problem relates to shared templates, site-wide content issues or technical factors.
In some situations, removing or combining unnecessary pages may be more useful than publishing more.
6. About Szymaniak Digital
Szymaniak Digital is a UK enterprise SEO and AI search consultancy.
When important pages disappear from Google without an obvious explanation, we help businesses investigate the scale of the decline, compare what Google rendered with what visitors see, review server logs and identify changes for content and development teams.
The goal is to move beyond repeatedly requesting indexing and hoping for the best. We focus on finding the likely cause, testing it and making changes that improve the website.
If your indexed page count has fallen and all the usual checks appear to pass, an investigation can help you understand what happened and decide what to do next.
