Resources · 31

Diagnose crawling and indexing of useful pages

Connect links, HTTP responses, directives, canonicals and Search Console evidence before fixing.

· 6 min

Fictional empty publication observatory with monitors and network equipment in a dark amber-lit office.

What this guide helps achieve

  • Select useful pages
  • Test discovery
  • Diagnose the gap
  • Retest

Quick check

  • Can an HTML link reach the page?
  • What response do visitors and crawlers receive?
  • Are robots, noindex and canonical signals coherent?
  • Does the page provide distinct value?
  • What does URL inspection show after a fix?

Step-by-step method

  1. 01

    Choose the priority set

    List important URLs with their intent, preferred canonical and actual last change. Exclude filters and pages without independent value.

    Deliverable: prioritized inventory and hypothesis per URL.

  2. 02

    Test discovery paths

    Follow HTML links from entry pages and compare them with the sitemap. A URL in a sitemap may still remain uncrawled or unindexed.

    Deliverable: paths, orphan pages and sitemap gaps.

  3. 03

    Check responses

    Verify HTTP status, redirects, availability, rendering and essential resources. Inspect robots rules and noindex directives separately.

    Deliverable: response and directive record.

  4. 04

    Inspect canonical selection

    Compare the declared canonical, internal links, sitemap and the page selected by the search engine. Canonical preference is a signal, not an absolute command.

    Deliverable: version cluster and contradictions.

  5. 05

    Combine observations

    Compare indexing reports, URL inspection and server logs where available. Separate discovery, crawl, rendering, canonical selection and indexing.

    Deliverable: dated diagnosis with confidence level.

  6. 06

    Fix and verify

    Repair the identified cause, retest the page and its links, submit useful changes and monitor their progress. Do not promise an indexing deadline.

    Deliverable: fix evidence and follow-up.

Management indicators

IndicatorWhat it measuresFirst action
DiscoveryPriority URLs reached by HTML linksFix architecture
ResponsePriority URLs with expected accessible statusRepair server and redirects
ConsistencyCanonical, sitemap and directives alignedResolve contradictions
Follow-upCauses documented and fixes retestedRevisit unproven cases

Common pitfalls

  • Treating sitemap inclusion as an indexing guarantee
  • Blocking robots from a page where noindex must be read
  • Changing canonicals at scale without reviewing variants
  • Blaming every gap on technology without assessing content

Frequently asked questions

Does a sitemap force indexing?

No. It can aid discovery but guarantees neither crawling nor indexing.

Is a declared canonical binding on Google?

It expresses a preference; Google may select another version using observed signals.

When is a fix confirmed?

After checking the likely cause, deployed correction and inspection evidence over an appropriate period.

Robots.txt: crawling, indexing and evidence

Read a crawl decision before drawing indexing conclusions

Discovering a URL, allowing crawling, indexing content and citing a source are separate stages. A 200 response and an Allow rule do not establish that a search engine selected the page. This reference shows which evidence belongs to each stage.

The three files and twelve requests below are fictional. IndexBot, PreviewBot and OtherBot do not identify real services. Examples use ASCII prefixes and an exact $ ending, without encoding, path wildcards, redirects or cache handling. Filters organise explained outcomes; they neither test a domain nor modify this site’s robots.txt.

Fictional empty publication observatory with monitors and network equipment in a dark amber-lit office.
Generated conceptual illustration: a fictional empty publication observatory. Screens show neither real traffic nor visibility measurements.
Three separate decisions: access, indexing, presentation
Three separate decisions: access, indexing, presentation Access checks and the served response precede crawling. The crawler must be able to read indexing directives. Indexing and preview restrictions precede potential presentation or citation; no stage guarantees the next. 1 · Access and crawling Rights HTTP response robots group 2 · Indexing and canonical Observed directives content duplicates 3 · Presentation and use Previews service scope selection

Access checks and the served response precede crawling. The crawler must be able to read indexing directives. Indexing and preview restrictions precede potential presentation or citation; no stage guarantees the next.

Compare three fictional robots.txt files

A · Specific groups and merging

IndexBot and INDEXBOT groups merge for the same case-insensitive token. PreviewBot uses its own group; it does not inherit restrictions from *.

User-agent: *
Disallow: /private/
Disallow: /search?

User-agent: IndexBot
Disallow: /private/
Disallow: /search?

User-agent: INDEXBOT
Allow: /private/public/
Disallow: /private/public/draft

User-agent: PreviewBot
Disallow: /preview/
B · Exact ending and equivalent rules

The $ suffix ends matching: /edition/brief and /edition/brief?view=print yield different outcomes. For the equivalent Allow and Disallow rules on /same, this example selects Allow.

User-agent: *
Disallow: /edition/
Allow: /edition/brief$
Disallow: /same
Allow: /same
C · No fallback group

OtherBot matches no group and there is no * group: no rules apply to it. The /archive/ name provides no access protection.

User-agent: IndexBot
Disallow: /archive/

Twelve rule decisions with their reasoning

Twelve rule decisions with their reasoning
Fictional requestApplicable groups and selected ruleCrawl decision and reason
A · IndexBot
/private/report		Groups 2 + 3

Disallow: /private/

Crawling disallowed

The two groups for this token are combined. Their common Disallow still applies.

A · IndexBot
/private/public/notice		Groups 2 + 3

Allow: /private/public/

Crawling allowed

The /private/public/ prefix is more specific than /private/, so this crawl is allowed.

A · indexbot
/private/public/draft		Groups 2 + 3

Disallow: /private/public/draft

Crawling disallowed

The draft prefix is more specific again, overriding the shorter Allow.

A · PreviewBot
/private/report		Groups 4

No matching rule

Crawling allowed

A specific group exists. The * group is not added; no /preview/ rule matches this request.

A · OtherBot
/private/public/notice		Groups 1

Disallow: /private/

Crawling disallowed

This crawler uses *. The Allow in IndexBot’s group does not apply to it.

A · OtherBot
/search?q=cyber		Groups 1

Disallow: /search?

Crawling disallowed

The rule includes the start of the query string. Parameters can change matching.

A · OtherBot
/Search?q=cyber		Groups 1

No matching rule

Crawling allowed

Path case matters in these examples. /Search does not start with /search.

B · OtherBot
/edition/brief		Groups 1

Allow: /edition/brief$

Crawling allowed

The request ends exactly at /edition/brief, matching the $ ending.

B · OtherBot
/edition/brief?view=print		Groups 1

Disallow: /edition/

Crawling disallowed

Parameters extend the URL after brief: the exact Allow no longer matches, while /edition/ still disallows.

B · OtherBot
/same		Groups 1

Allow: /same

Crawling allowed

Both rules have the same path. The example follows the Allow preference for equivalent rules.

C · OtherBot
/archive/report		No group

No matching rule

Crawling allowed

Neither a group for OtherBot nor a * fallback exists: no REP restriction applies.

C · IndexBot
/archive/report		Groups 1

Disallow: /archive/

Crawling disallowed

The IndexBot group matches and its /archive/ prefix disallows this crawl.

Six checks against the file actually served

Six checks against the file actually served
CheckDocumented interpretationSource and passage
Scope/robots.txt concerns the target service. Google scopes it by host, protocol and port; check subdomains separately.IETF · RFC 9309 — Robots Exclusion Protocol

§2.3

FormatThe protocol specifies UTF-8, text/plain and a lowercase file name at the service root.IETF · RFC 9309 — Robots Exclusion Protocol

§2.3

SizeThe RFC requires parsing capacity of at least 500 KiB; Google documents its own 500 KiB limit. These are different statements.IETF · RFC 9309 — Robots Exclusion Protocol

§2.5; Google documentation, File format

CacheThe RFC recommends not using a cached copy beyond 24 hours unless the file is unreachable. A change may not be observed immediately.IETF · RFC 9309 — Robots Exclusion Protocol

§2.4

404 or 403The RFC permits the crawler to access resources in this situation. Google treats 4xx except 429 as no crawl restrictions: 403 on robots.txt does not protect pages.Google · Interprétation de robots.txt / robots.txt interpretation

Handling of errors

Server errorThe RFC requires assuming complete disallow when the file is unreachable. Google documents its own 5xx sequence, starting with a 12-hour crawl stop; do not reduce every case to permanent refusal.Google · Interprétation de robots.txt / robots.txt interpretation

Handling of errors

Six situations: what the signals establish

Six situations: what the signals establish
Fictional situationWhat is establishedWhat still needs checking
200, crawling allowed, no observed noindexThe content can be read; these signals do not individually exclude it.Actual indexing, selected canonical, content quality and result selection.
Disallow and noindex in the pageA crawler respecting disallow does not read the page’s directive.Links can still make the URL known. Make an indexing exclusion observable to the relevant engine.
200 and observable noindexThe directive requests exclusion from a supporting index after processing.Recrawl timing and observed state; this is not protection against human access.
200 and canonical pointing elsewhereA canonical preference is expressed. For Google this is a signal, not an absolute command.Target relevance and agreement between links, sitemap and the selected canonical.
URL included in a sitemapThe publisher proposes a URL for discovery; Google treats inclusion as a weak canonical signal.Response, directives, useful content and actual indexing.
Private page behind authorisationThe server or application must refuse unauthorised access.Test rights with dedicated accounts; robots.txt never replaces this boundary.

Compare AI controls and report data →

Primary sources and scope

REP rules come from RFC 9309; Google-specific details are attributed to its own documentation. Examples and the diagram are educational. Filtering performs no crawling and the tables contain no client results.

References reviewed

IANA references and DNSSEC interpretation

Successful resolution enables access, not indexing

DNS enables reaching a destination; DNSSEC validation concerns DNS data authenticity. Neither guarantees crawling, indexing or ranking.

  • Separate DNS observations from HTTP status and indexing directives.
  • Do not infer a crawler’s recovery time from TTL alone.
  • Keep changes and checks by layer to explain what was actually restored.

Read the registries and try the cache model →

IETF · RFC 4033 · §3–5 · 2026-10-23

Official references

References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.

Continue exploring

← All guides Next guide : Design accessible forms and recoverable errors → Explore the service