Building useful websites
Page not indexed by Google? Diagnose one URL before changing your site
Start with one important page and one recorded observation. This checklist helps you distinguish a fixable publishing mistake from an indexing decision you cannot force.
Start with the exact page
Choose a public article that should appear in search. Copy its complete address, including https, hostname and path. In Search Console, open a property that covers that address and inspect the URL. Save the reported reason and last crawl time, if shown.
The normal inspection report describes Google’s stored version. Test live URL checks the current page; a successful live test does not establish that the page is indexed. Keep the two results in separate notes. Source: Google’s URL Inspection guide, linked below.
Before changing anything, answer: should this exact address be searchable? A private draft, a retired page or an old address that redirects may be excluded intentionally. This checklist is for a public page you want readers to find.
1. Check whether Google can read the page
Open the address while signed out. Does it show the complete article, a login screen, an error or a different address? Record what happens. A successful visit from your browser is useful evidence, but does not prove that Google can fetch it.
If inspection reports a fetch or server error, investigate that failure first. If it reports a robots.txt block, review the rule for this hostname and path. Remove only an unintended block on the public page. Ask your hosting provider to trace the exact URL if you cannot inspect the configuration.
- Record the final address after any redirects.
- Check that the main article is present, not only a page title or loading message.
- Retest the current page after a repair; keep the older crawl result dated.
2. Check for an accidental noindex
Google can receive noindex from the page’s robots meta tag or an X-Robots-Tag response header. If a public article inherited a draft setting, remove that unintended instruction where it is generated. Check both the page and its response headers.
A robots.txt block can stop Google from reading a noindex instruction. These controls are not interchangeable. Do not remove a deliberate exclusion from a private or unpublished page just to make a report green. Source: Google’s noindex guide.
3. Compare the preferred and selected URLs
Canonical means the preferred representative of duplicate or very similar pages. Compare the user-declared canonical with Google’s selected canonical when the report provides them. Open both addresses and check whether they contain the same useful material.
If the selected address is the intended version, you may have no problem to fix. If your article accidentally points to a different article, repair the template or page setting. Make internal links, sitemap entries and the canonical preference agree. A canonical annotation is a signal, not a command that guarantees Google’s choice. Source: Google’s canonical URL guidance.
4. Choose an action for a waiting state
Separate a concrete defect from a hypothesis. “The article has an unintended noindex” is actionable evidence. “Google dislikes this topic” is not established by a waiting status. Record a later review date instead of repeatedly changing the URL.
- Discovered — currently not indexed: Google knows the address but has not crawled it. Check that a useful, reachable index page links to the article and that the sitemap lists the intended address.
- Crawled — currently not indexed: Google has fetched it but has not added it to the index. Review what the page actually contributes and whether another page already answers the same need. The status alone does not identify the cause; Google’s report documentation says resubmission is unnecessary for this state.
- A submitted sitemap helps discovery; it does not guarantee crawling or indexing. Keep the sitemap accurate rather than treating repeated submission as a repair.
Two worked examples
Example A — a fictional repair guide: the page opens normally, but the live test reports noindex. The publisher finds a draft setting still active. Next action: remove that setting for the public guide, retest and record the result. Even if the live test then passes, write “current exclusion removed; indexing not yet confirmed”.
Example B — a fictional workshop timetable: the report says Discovered — currently not indexed. The timetable is available, linked from the workshop index and included in the sitemap. There is no identified technical defect. Next action: retain the stable address, check that the timetable answers visitors’ questions, and set a later observation. Do not invent a successful indexing result.
These examples illustrate decisions, not measurements from real sites or a guaranteed waiting period.
Copy this one-URL record
For a small new site, a practical editorial default is to review this record again in a week, sooner if a concrete failure appears. That interval is our workflow choice, not a Google indexing deadline. Once indexing is confirmed, observe search impressions, clicks and article views separately: they answer different questions.
- Exact URL and why a reader needs this page: …
- Observation date; stored inspection reason; last crawl date or “not shown”: …
- Current live-test result, kept separate from stored status: …
- Fetch access; noindex; declared and selected canonical: …
- Link from a useful page; sitemap entry: …
- Evidence-backed defect, or “none identified”; next action and review date: …
- Outcome: current defect fixed / indexing confirmed / still unknown: …