Technical GEO procurement
A buyer's checklist for crawl and index readiness
Separate publication, crawlability, indexability, indexing and observed visibility, then ask a GEO supplier for evidence at each stage.
Published by SALIENS · Published
Do not accept 'live' as proof of search visibility
A page can be deployed and open in a browser without being crawled, indexed or shown for a relevant query. These are separate states with different evidence. A useful GEO scope names the stage it will change, the test it will run and the record it will return.
Google's URL Inspection documentation makes the same distinction. Its live test checks whether Google can access and parse the current page, but a positive result does not guarantee indexing. The indexed report describes the version Google last processed, which can differ from the page now online. Even a 'URL is on Google' result does not guarantee that the page will appear in a particular search result.
Define five statuses before work begins
Use a fixed vocabulary in the brief and report. This prevents a successful deployment check from being presented as an indexing result, or an isolated search observation from being treated as continuing visibility.
- Published: the agreed URL is publicly available, returns the intended page and resolves to the recorded final URL.
- Crawlable: the named crawler or inspection tool could fetch the page under recorded conditions, with no login, robots rule or response failure preventing access.
- Indexable: the tested page exposes no known directive or technical state that prohibits indexing. This is eligibility evidence, not an indexing promise.
- Indexed: an authorised platform report records the URL in its index, together with the inspection date, last crawl and selected canonical where available.
- Observed: a dated test or platform report records an appearance, mention, citation, impression, click or enquiry under stated query, market, language, interface and device conditions.
Use one evidence table for every priority URL
Agree the priority URL set before the supplier starts. For each URL, require the source, date and result of every test. A blank field remains 'not obtained'; it is not a zero and should not be converted into a success claim.
| Stage | Evidence to request | Acceptance record |
|---|---|---|
| Published | Final public URL, response result, page title, deployment or publication reference and check time. | URL: ___; result: ___; checked: ___ |
| Crawlable | Named crawler or live inspection result, user agent where relevant, fetch result and blocking reason if unsuccessful. | Tool: ___; fetch: ___; blocker: ___ |
| Indexable | Indexing directive, robots access, user-declared canonical, rendered content and sitemap inclusion checked against the intended state. | Controls: ___; exception: ___; owner: ___ |
| Indexed | Authorised index report with status, inspection date, last crawl and platform-selected canonical where available. | Source: ___; status: ___; canonical: ___ |
| Observed | Exact query or report, platform/interface, market, language, device and observation date, with mention, citation and website action kept separate. | Conditions: ___; result: ___; date: ___ |
Check the controls without overstating them
Ask the supplier to inspect robots access, indexing directives, redirects, canonical declarations, internal discovery and sitemap inclusion. These are controls and signals, not proof that a search or AI system has selected or displayed the page.
A robots.txt block is not the same as noindex. Google explains that if crawling is blocked, it may not see a noindex directive on the page. A sitemap can help discovery, but sitemap inclusion does not prove indexing. A declared canonical is also a preference: Google may choose another canonical, and its live test cannot predict that choice.
Require an exception list and a retest
The delivery should identify every URL that did not meet the agreed condition, the evidence behind the finding, the proposed action, the implementation owner and the retest date. Separate access problems, deployment defects, crawl restrictions, indexing directives, duplicate or canonical issues and observations that are simply unavailable.
Confirm who can access Search Console or another authorised platform report. If the supplier cannot access it, the indexed column should remain explicitly unverified until the client supplies evidence. Public spot checks can support diagnosis, but they are not a substitute for property-level records or a complete measurement method.
Buy the stage your team can actually complete
A technical audit can identify readiness issues, but it does not implement or publish fixes unless the scope says so. Monitoring can record changes, but it does not by itself create content or resolve defects. Before commissioning work, assign approval, implementation, publication and verification responsibilities to named parties.
SALIENS provides GEO audits, AI visibility monitoring, content and technical improvements, and ongoing GEO delivery for UK and international organisations. We can build this evidence register into the agreed scope and keep publication, indexing, visibility and enquiry outcomes distinct. Email info@oxfordintelligence.co.uk with your website, priority markets and the URLs you need to assess. SALIENS is operated by Oxford Intelligence Limited; search engines and AI platforms decide what they crawl, index, cite and display, so those outcomes are not guaranteed.
Sources
- Google Search Console Help: URL Inspection tool (checked 21 September 2026)
- Google Search Central: Block Search indexing with noindex (checked 21 September 2026)
- Google Search Central: Specify a canonical URL (checked 21 September 2026)
- Google Search Central: AI features and your website (checked 21 September 2026)
Prepared with AI assistance using the linked sources and SALIENS service information.
