On this page
- RNX-111 · Manifest Optimization & Ingestion Speed
- RNX-112 · Crawl Budget & Block Resolution
- RNX-113 · Canonical Consolidation
- RNX-114 · AI Manifest Priority Mapping
- RNX-115 · Token-to-Value Optimization
- RNX-116 · Authenticated Agent Accessibility
- RNX-117 · Semantic Compression Ratio
- RNX-118 · Agentic Retrieval Negotiation
- RNX-110.T001 · Sitemap syntax
- RNX-110.T002 · Sitemap partition limits
- RNX-110.T003 · Sitemap URL eligibility
- RNX-110.T004 · Sitemap modification truth
- RNX-110.T005 · IndexNow key ownership validation
- RNX-110.T006 · IndexNow receipt interpretation
- RNX-110.T007 · IndexNow deleted-URL notification
RNX code library · 47 controls
RNX-110Technical Discoverability & Ingestion Efficiency
Read what these checks mean, why they matter and which evidence they concern. Each ID below keeps its canonical place in the RNX hierarchy.
These are free learning summaries, not full technical tests or an industry certification. Specialized checks apply only to the relevant feature. Experimental labels are preserved from the canonical source.
RNX-110.T001
Sitemap syntax
core readiness
Check that a sitemap is readable and lists complete web addresses.
Why it matters. A broken map may not help a crawler find your pages.
Illustration — fictional. A formatting error makes the sitemap unreadable to the tool that processes it.
When it applies. Inspected target: sitemap document. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-110.T002
Sitemap partition limits
core readiness
Check each sitemap against its size and address-count limits.
Why it matters. Oversized files may not be processed as expected.
Illustration — fictional. A sitemap contains more addresses than the protocol permits in one file.
When it applies. Inspected target: sitemap document. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-110.T003
Sitemap URL eligibility
core readiness
List the preferred public pages you want discovered.
Why it matters. Shopping carts and deliberately excluded duplicates can make the map misleading.
Illustration — fictional. A sitemap includes a private shopping-cart address deliberately excluded from search.
When it applies. Inspected target: sitemap entry. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-110.T004
Sitemap modification truth
core readiness
Use update dates only when they reflect meaningful changes.
Why it matters. Rewriting every date on every build gives a false freshness signal.
Illustration — fictional. Every website rebuild changes every sitemap update date, even though the pages have not changed.
When it applies. Inspected target: sitemap entry. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-110.T005
IndexNow key ownership validation
core readiness
If using IndexNow, establish ownership of the addresses being submitted.
Why it matters. A notification service should not accept an unsupported claim of control.
Illustration — fictional. The ownership file contains a different key from the one submitted with the notification.
When it applies. Inspected target: indexnow key. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-110.T006
IndexNow receipt interpretation
core readiness
Call an accepted IndexNow notification a receipt.
Why it matters. It does not prove indexing, ranking or an AI citation.
Illustration — fictional. An accepted change notification is reported as proof that the page is indexed and ranking.
When it applies. Inspected target: indexnow receipt. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-110.T007
IndexNow deleted-URL notification
core readiness
Include removals when an IndexNow integration is meant to report them.
Why it matters. Otherwise the change feed tells only part of the site's update story.
Illustration — fictional. A removed page is never sent through an integration that is meant to report removals.
When it applies. Inspected target: removed url event. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-111 · Manifest Optimization & Ingestion Speed
RNX-111.T001
Optional llms.txt consumer evidence
Experimental — not an established ranking requirement
For an optional llms.txt file, identify a consumer that actually supports it.
Why it matters. A file's existence is not evidence that all AI services use it.
Illustration — fictional. An optional AI text file is advertised as a requirement used by every search provider.
When it applies. Inspected target: manifest consumption. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112 · Crawl Budget & Block Resolution
RNX-112.T001
DNS resolution
core readiness
Check that the website's name leads to the intended server.
Why it matters. An old address record can send visitors to a retired website.
Illustration — fictional. The domain still points to the old server after the website moves.
When it applies. Inspected target: hostname. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T002
TLS identity
core readiness
Check that the site's security certificate is valid for its name.
Why it matters. A mismatch can prevent a safe connection.
Illustration — fictional. A shop's security certificate covers a different domain, so visitors see a connection warning.
When it applies. Inspected target: hostname. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T003
Public response availability
core readiness
Check that a public page returns usable content successfully.
Why it matters. A server error can block customers and crawlers alike.
Illustration — fictional. The public booking page repeatedly returns a server error instead of the booking details.
When it applies. Inspected target: url. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T004
Redirect termination
core readiness
Follow address changes to make sure they end at the right page.
Why it matters. A redirect loop sends visitors in circles.
Illustration — fictional. The old address sends people to the new address, which sends them straight back to the old one.
When it applies. Inspected target: url trail. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T005
Robots syntax
core readiness
Check that the robots.txt rules can be understood as intended.
Why it matters. Broken instructions may not control crawler access as the owner expects.
Illustration — fictional. An incorrectly written group of crawler rules is ignored rather than applied as the owner intended.
When it applies. Inspected target: robots document. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T006
Crawler-specific permission
core readiness
Check permission for the particular crawler and public page being tested.
Why it matters. One crawler's access does not establish another's.
Illustration — fictional. A broad crawl restriction accidentally blocks the search crawler the owner meant to allow.
When it applies. Inspected target: crawler url pair. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T007
Robots versus authentication boundary
core readiness
For private pages, require real access checks even when robots.txt discourages crawling.
Why it matters. A crawl rule does not protect invoices or account details.
Illustration — fictional. A customer invoice can be opened without signing in, despite a rule asking crawlers to stay away.
When it applies. Inspected target: private url. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T008
Bot identity verification
core readiness
Verify evidence before calling a visitor an official bot.
Why it matters. Anyone can send a request that uses a familiar crawler name.
Illustration — fictional. A request claims to be Googlebot, and the report accepts that name without checking the visitor's identity.
When it applies. Inspected target: log record. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T009
WAF challenge obstruction
core readiness
Check that security challenges do not block approved, verified crawlers.
Why it matters. A challenge screen is not the content you intended them to read.
Illustration — fictional. The site's security service gives an approved crawler a challenge screen instead of the service description.
When it applies. Inspected target: verified bot request. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T010
Crawl demand diagnosis
core readiness
Separate useful and duplicate addresses in crawl records.
Why it matters. This shows where visits go without pretending that unknown traffic is useful.
Illustration — fictional. A crawl report drops addresses it cannot classify and calls every remaining visit useful.
When it applies. Inspected target: log interval. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T011
Robots error-path behavior
core readiness
Interpret robots.txt errors using the relevant crawler's documented rules.
Why it matters. A failed request does not always mean access is allowed.
Illustration — fictional. A tool treats every failed robots.txt request as permission to crawl.
When it applies. Inspected target: robots error fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T012
OpenAI independent-purpose policy
core readiness
For OpenAI crawler settings, separate search access from model-training access.
Why it matters. Agreeing to one purpose should not be described as a requirement for the other.
Illustration — fictional. A setting meant to block model-training visits accidentally blocks search visits the owner wanted to allow.
When it applies. Inspected target: crawler purpose pair. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T013
ChatGPT user-fetch inference boundary
core readiness
Do not treat a user-requested ChatGPT fetch as proof of search inclusion.
Why it matters. The purpose and route of the visit matter.
Illustration — fictional. A page fetched at a user's request is treated as proof of search indexing.
When it applies. Inspected target: user-fetch inference. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T014
Anthropic role-specific policy coverage
core readiness
For Anthropic, consider each documented crawler purpose separately.
Why it matters. A single assumed switch can misrepresent the owner's choices.
Illustration — fictional. A broad crawler rule blocks a search purpose that the owner meant to approve separately.
When it applies. Inspected target: crawler purpose matrix. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T015
Perplexity IP-list update provenance
core readiness
For a Perplexity network allowlist, record the official source and its age.
Why it matters. Outdated network data may block intended access or allow the wrong traffic.
Illustration — fictional. Old copied list has no source or refresh date.
When it applies. Inspected target: network allowlist. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-112.T101
Dated Bing AI preference transition plan
Experimental — not an established ranking requirement
For Bing AI preference changes, record a dated transition plan tied to current provider guidance.
Why it matters. Old settings should not be assumed to control a new system.
Illustration — fictional. A transition plan says a new provider preference is already enforced before the documented effective date.
When it applies. Inspected target: transition plan. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113 · Canonical Consolidation
RNX-113.T001
Unintended noindex
core readiness
Check for accidental instructions that exclude an intended search page.
Why it matters. A leftover noindex setting can keep a finished page out of search.
Illustration — fictional. A launch template accidentally tells search engines not to index the finished service page.
When it applies. Inspected target: url directives. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T002
Exclusion visibility
core readiness
Let the crawler encounter the exclusion instruction you want it to follow.
Why it matters. Blocking the whole page can hide that instruction too.
Illustration — fictional. A crawler is blocked from the page and therefore cannot read the instruction to exclude it from indexing.
When it applies. Inspected target: url directives. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T003
Snippet permission
core readiness
Check that preview restrictions match your publishing choice.
Why it matters. Accidentally banning snippets may prevent the previews you intended to allow.
Illustration — fictional. An accidental setting bans search previews across a site whose owner wants previews enabled.
When it applies. Inspected target: url directives. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T004
Non-HTML exclusion
core readiness
For files such as PDFs, check that intended exclusion instructions reach the crawler.
Why it matters. Rules placed only on an unrelated web page do not cover the file.
Illustration — fictional. A PDF meant to be excluded is served without the exclusion instruction intended for that file.
When it applies. Inspected target: file response. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T005
Canonical target validity
core readiness
Point a duplicate-page preference to the correct equivalent page.
Why it matters. An unrelated homepage is not a substitute for a product or service page.
Illustration — fictional. A service page labels an unrelated homepage as its preferred equivalent.
When it applies. Inspected target: canonical edge. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T006
Canonical signal consistency
core readiness
Keep duplicate-page preferences, internal links and sitemaps in agreement.
Why it matters. Conflicting preferred addresses make your intentions harder to interpret.
Illustration — fictional. The sitemap favors one copy of a product page while the site's links favor another.
When it applies. Inspected target: canonical graph. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T007
Paginated canonical meaning
core readiness
Do not call later list pages copies of page one when their content differs.
Why it matters. Each page may contain items readers still need to find.
Illustration — fictional. Page three lists different products but labels itself as a copy of page one.
When it applies. Inspected target: pagination url. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T008
Index state provenance
core readiness
Separate a page being reachable now from proof that a search engine has indexed it.
Why it matters. These are different observations made at different times.
Illustration — fictional. A tool opens a page successfully and reports it as already indexed without search-provider evidence.
When it applies. Inspected target: inspection record. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T009
Soft-404 classification
core readiness
Give missing content an honest error or a useful replacement.
Why it matters. An empty page labeled successful misleads both visitors and tools.
Illustration — fictional. An empty missing-product page still sends a success response to the browser.
When it applies. Inspected target: url response. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T010
Migration mapping
core readiness
When moving a site, give important old pages suitable destinations or intentional removals.
Why it matters. Sending everything to the homepage loses the visitor's purpose.
Illustration — fictional. All old products redirect to homepage.
When it applies. Inspected target: old url. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T011
Staging isolation
core readiness
Protect private test versions with access controls.
Why it matters. Unreleased material should not become public just because its address is hard to guess.
Illustration — fictional. An unfinished test site is accessible to anyone who knows its address.
When it applies. Inspected target: staging url. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T012
Hreflang target validity
core readiness
For multilingual pages, point language-and-region labels to real suitable versions.
Why it matters. Broken alternatives cannot serve the intended reader.
Illustration — fictional. A locale annotation points to the wrong language or a missing URL.
When it applies. Inspected target: declared alternate URL. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T013
Hreflang reciprocity
core readiness
Check the required return links between declared language versions.
Why it matters. One-sided relationships can leave the intended grouping unclear.
Illustration — fictional. English declares a French alternate but the French page has no return annotation.
When it applies. Inspected target: declared reciprocal alternate pair. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T014
Locale canonical compatibility
core readiness
Keep preferred-page choices compatible with the language versions you want available.
Why it matters. A conflicting choice can undermine an intended local version.
Illustration — fictional. Every translated page points to English as the preferred copy, despite containing distinct translated content.
When it applies. Inspected target: locale canonical and alternate relationship. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T015
Locale discovery without georedirect
core readiness
Let people and crawlers reach other language versions without forced redirection.
Why it matters. A location guess should not lock them out of a useful page.
Illustration — fictional. The server forces a visitor to one locale and prevents access to an explicitly chosen alternate.
When it applies. Inspected target: locale URL discovery journey. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T101
Locale annotation token validity
core readiness
Use valid, accurate language and region labels for alternate pages.
Why it matters. A working link can still be labeled as the wrong language.
Illustration — fictional. uk is used to mean the United Kingdom rather than the Ukrainian language.
When it applies. Inspected target: hreflang token set. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T102
Alternate group semantic equivalence
Experimental — not an established ranking requirement
Group language alternatives that serve the same purpose.
Why it matters. A translated product page should not be paired with an unrelated homepage.
Illustration — fictional. An English product page points to the French homepage as its translation.
When it applies. Inspected target: equivalent locale page group. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-113.T103
Alternate publishing mechanism consistency
Experimental — not an established ranking requirement
Keep language alternatives consistent wherever they are published.
Why it matters. A page and sitemap should not point to different supposed translations.
Illustration — fictional. The page points to the current German product while its sitemap points to an obsolete alternative.
When it applies. Inspected target: alternate mechanism comparison. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-114 · AI Manifest Priority Mapping
RNX-114.T001
Named manifest contract
Experimental — not an established ranking requirement
For a machine-readable manifest, tie priority and freshness fields to a named supported contract.
Why it matters. Otherwise they are experimental labels, not universal instructions.
Illustration — fictional. A made-up priority field is claimed to control how Google crawls the site.
When it applies. Inspected target: manifest. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-115 · Token-to-Value Optimization
RNX-115.T001
Named-tokenizer cost measurement
Experimental — not an established ranking requirement
For text-cost tests, name the tool that counts tokens and the text it counted.
Why it matters. Different tools may split words differently, so one count is not universal.
Illustration — fictional. A text-cost report hides which counting tool and input it used, so nobody can reproduce the result.
When it applies. Inspected target: token count record. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-116 · Authenticated Agent Accessibility
RNX-116.T001
Private retrieval authorization
Experimental — not an established ranking requirement
For private retrieval services, reject requests lacking the required authorization.
Why it matters. Calling a requester an agent does not entitle it to private records.
Illustration — fictional. A caller receives a private document despite having permission for a different task only.
When it applies. Inspected target: retrieval request. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-117 · Semantic Compression Ratio
RNX-117.T001
Compression fidelity
Experimental — not an established ranking requirement
For shortened content, preserve important facts and limits.
Why it matters. A smaller text is not an improvement if it changes the meaning.
Illustration — fictional. Not available becomes available after compression.
When it applies. Inspected target: critical fact. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-118 · Agentic Retrieval Negotiation
RNX-118.T001
Retrieval negotiation conformance
Experimental — not an established ranking requirement
For a service offering different retrieval formats, follow its declared request rules.
Why it matters. Unsupported choices need an honest fallback or error.
Illustration — fictional. A service promises a structured data response but always returns an ordinary web page instead.
When it applies. Inspected target: negotiation case. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.