A page missing from your search results is not necessarily missing from Google's index. And a page that is not indexed has not automatically been penalised. To decide what to fix, start with the exact URL, the information available in Search Console and the real state of the page.
The goal is not to get every address a site generates into the index. It is to let Google discover and index the useful versions of your content. Sorting parameters, technical duplicates, staging copies and private pages can legitimately stay out of the results.
What follows is a diagnostic order: identify the URL, read the status, rule out access problems, then look at duplication and at the content itself. That order avoids the most common waste of effort, which is rewriting a page Google has never been able to fetch.
Start with the exact URL and the right property
Open URL Inspection in the Search Console property that matches the site. Check the protocol, the subdomain and the final address after any redirect. Two close variants can carry different statuses, and a report about https://www.example.com/page/ tells you nothing about https://example.com/page.
The inspection tool separates index data from the live test. Index data describes the version Google knows about. The live test examines access right now. A live test that passes does not mean the page has just been indexed, and it does not predict every decision Google will make.
Note the date of the last crawl, the fetch state and the selected canonical when it is shown, then compare them against the dates of your own changes. A report based on an earlier crawl cannot tell you that your latest fix has failed; it only tells you what Google saw before that fix existed.
The site: operator is a useful secondary signal, but its results are not exhaustive. Do not treat an empty site: query as proof that a page is absent from the index.
Read the status without inventing a cause
The page indexing report separates indexed and non-indexed URLs and gives a reason for each group. Inspect one representative example before you extend a diagnosis to the whole site. A reason describes what happened, not why it happened on your site.
| Status | What it lets you conclude | Useful check |
|---|---|---|
| Discovered, currently not indexed | The URL is known, with no crawl recorded | How it was discovered, server availability, site context |
| Crawled, currently not indexed | Google fetched the page and did not index it at this stage | Rendered content and what the page adds on its own |
| Alternate page with proper canonical tag | Another version is treated as representing the content | Whether that version matches the one you chose |
| Excluded by noindex tag | A directive is asking for exclusion | Whether the directive is deliberate or left over |
| Server error (5xx) | The request failed | Server logs, uptime, load at the time of the crawl |
"Crawled, currently not indexed" is the status that generates the most guesswork. On its own it is neither a quality score nor evidence of a manual action. Look for something verifiable before you decide the text has to be rewritten, lengthened or deleted. If you are working through a backlog of these URLs, it helps to scope the work as a proper audit rather than reacting URL by URL.
Rule out technical obstacles first
Google's minimum technical requirements cover crawler access, a valid HTTP response for the page and content that can be indexed. A page that opens perfectly in your logged-in admin session can still be unreachable for the public or for Googlebot.
Check the response that is actually served
Test the URL without a session on the site: a private window or a command-line request. Check the HTTP status code, the redirect chain, the certificate and any protection layer that filters requests. A one-off failure and a repeated outage call for different investigations, and hosting logs usually place the problem in time.
Check the body as well as the header. A 200 response carrying an error message, an empty template or a "nothing found" screen is not a normal page. A soft 404 is exactly this mismatch between the status code and what the visitor sees. Fix the content or the status, but do not leave the two contradicting each other.
Separate crawling from indexing
A rule in robots.txt blocks crawling of the matching paths. It is not a reliable way to remove a URL that Google already knows about. The noindex directive has to be readable by Google to take effect, which means the page must remain crawlable.
Inspect both places a directive can sit: the robots meta tag in the rendered HTML and the HTTP response headers.
curl -I https://example.com/your-page/
# 1. in the HTTP response headers
x-robots-tag: noindex
# 2. in the rendered HTML of the page
<meta name="robots" content="noindex">A setting kept after a migration, a staging environment copied into production, or two plugins writing the same tag can all leave an unexpected directive behind. Injected pages and altered templates on a compromised WordPress install produce the same symptom. Fix the source of the setting, then check the final HTML and the headers again. Changing an option in an interface without verifying the response is not a verification.
Make sure the page can be discovered
An important page should be linked from relevant content or from the navigation. Google's documentation asks for crawlable HTML links with a real href. There is no universal four-click threshold beyond which a page is dropped, and no number of internal links that guarantees inclusion.
Avoid loading the main content only after a visitor action such as a click on a tab or an infinite-scroll trigger. JavaScript rendering deserves a specific check whenever the HTML received, or the HTML rendered, does not contain what you expect to see.
Look at canonicals and near-duplicate pages
When Search Console reports that another URL represents the page, compare the two versions and the signals you send about them: internal links, sitemap entries, redirects and the declared canonical. Canonicalisation indicates a preferred version; Google can select a different one when the signals or the content point elsewhere.
Two addresses serving the same content do not need two artificially different texts. The reverse also applies: two genuinely distinct services should not share a canonical simply because they use the same page template.
Before merging anything, write down what each URL contributes and which links point to it. A page can keep its value for visitors, hold external references or support a commercial commitment even if it is not indexed. If you are consolidating several thin pages into one, decide on the destination and the redirects before you touch the content itself.
Judge the content without arbitrary quotas
If no technical obstacle is confirmed, read the page as its audience would. Does it answer a precise question? Does it contain what the title promises? Does it offer an explanation, a method or data that go beyond the shared template of the site?
Google does not recommend a minimum text length. A short page can do its job; a long page can stay repetitive. Add what is missing because a reader needs it, not to reach a word count someone quoted to you.
An older publication is not defective because of its age. Update the information that has changed, keep the dates that historical events require, and do not edit a publication date to simulate freshness. Usage data can reveal a reading or navigation problem, but no universal bounce rate or time-on-page threshold diagnoses a non-indexed URL.
Fix, verify, then follow up
Keep a record of the defect you observed and the change you intend to make. When several pages share a template, test one representative fix before rolling it out. Make sure links, media and useful information survive the change.
- Check the current response and the content after the fix, from outside your session.
- Compare the crawl date against the date of your change before drawing conclusions.
- Confirm that the page is still linked from somewhere relevant on the site.
- Keep the sitemap consistent with the URLs you actually want discovered.
- Track indexing first, then impressions and clicks, in that order.
After a substantial change you can ask Google to recrawl a URL, or use a sitemap for a set of pages. Repeating the request does not speed up processing. Timescales vary, and a request never guarantees inclusion. Our notes on how indexing is handled in practice go further into that follow-up work.
If the situation persists, go back to the facts: has a new crawl happened, is the same content still being served, is the expected canonical selected, and does the problem follow a template. That sequence is far more useful than a run of changes to titles, dates and word counts whose individual effect you can no longer isolate.
Common questions
Does "crawled, currently not indexed" mean I have been penalised?
No. The status says a crawl took place and indexing did not follow at that point. On its own it gives neither the cause nor any evidence of a manual action. Treat it as a prompt to check access, duplication and the usefulness of the page.
The live test passes. Is the page indexed?
Not necessarily. The live test checks current access and some technical points. Index data is separate, and the test does not predict every condition for inclusion or the final canonical choice.
Should I make a page longer so that it gets indexed?
Only if useful information is genuinely missing. Google publishes no minimum word count. Check access, directives, possible duplicates and the answer the page gives the reader first; length is a consequence of those decisions, not a fix in itself.
Can I combine robots.txt and noindex to remove a page?
If robots.txt prevents Google from crawling the page, the crawler may never read the noindex on it. Keep the two controls separate: crawling is managed in robots.txt, indexing through the meta tag or the HTTP header. Then check the response that is actually served.
Should non-indexed pages be deleted?
Not automatically. Check what they are for, which links point at them, where they sit in the journey and any commitments attached to them. Some exclusions are normal, and a page can be useful without being an entry point from Google.
How often should I request indexing?
A request makes sense after a meaningful correction. Repeating it without changing anything does not accelerate crawling. Follow the date of Google's last visit and the status of the corrected version instead.