Use these templates to check whether approved public pages and documents can be reached, processed, accurately described, and used by readers. Part D’s practice register, biographies, credential checks, and change records supply the approved facts. Part E retains technical and indexing evidence; Part C records subsequent AI-answer observations.
Keep access, index eligibility, confirmed index inclusion, and observed retrieval or citation separate. A successful technical test establishes only the behavior tested. The checklists below are proposed operating templates; provider-specific examples reflect documentation checked in October 2026. Record the applicable source and recheck it before implementation.
E.1 Crawler access
Access policy record
[Host/path or asset group; intended audience; named crawler/product; documented purpose; desired access; enforcement controls; policy owner; approval/date; provider documentation/date; expected test result].
Set policy separately for public discovery, model training, user-requested retrieval, and private content. A correctly protected client portal can pass its access check while an unintentionally blocked public biography fails.
Operator-specific example
OpenAI’s crawler documentation distinguishes the following purposes and controls.
Agent | Purpose and policy implication |
OAI-SearchBot | Supports ChatGPT search. Record the firm’s search-access decision and check the relevant robots.txt and network rules. |
GPTBot | Crawls material that may be used for model training. Make this decision independently of search access. |
ChatGPT-User | Supports certain user-initiated requests. OpenAI states that robots.txt rules may not apply to these requests; this agent does not determine Search inclusion. |
Extend the record for other relevant providers using their current documentation. Avoid treating every agent with “AI” in its description as the same service.
Access checklist
Check | Evidence to retain |
| Fetch the production robots.txt for each relevant host. Record the rule applying to the named agent and representative paths, including downloads and subdomains. |
| Inspect content delivery network and web application firewall decisions, rate limits, and server errors. Retain response headers, timestamps, and relevant logs. |
| Confirm that a request receives the intended content, including important qualifications, rather than a login, consent interstitial, challenge, or empty response. |
| Check access to files, images, styles, scripts, and endpoints needed to retrieve or render the approved content. |
| Confirm that client workspaces, confidential files, and nonpublic environments retain their intended authentication and access restrictions. |
Label a request using a crawler-like user-agent string as a synthetic test. It does not prove that the real crawler reached the site. Record actual crawler requests separately and verify their identity using the operator’s documented method where available.
Robots.txt controls crawling; it is not an access-security mechanism or a dependable way to remove a URL from Google. To act on a page’s noindex instruction, Google must be able to fetch that instruction. A robots block can prevent this. Use authentication for private content and evaluate public indexing controls separately.
E.2 Indexing and content delivery
URL inventory
[URL/asset ID; page or file type; practice/person ID; language/jurisdiction; intended audience; preferred canonical; internal discovery path; sitemap; expected indexing/preview behavior; owner; last change].
Sample the homepage, each important practice template, biographies, articles, document landing pages, actual downloads, language variants, and retired URLs. Record the selection method and expand testing when a shared template fails.
Indexing checklist
Check | Evidence to retain |
| Requested URL, redirect chain, final URL, HTTP status, content type, and actual body. Confirm that successful responses contain the intended content and retired URLs behave as planned. |
| Working internal links from relevant pages, usable navigation, and sitemap entries where intended. Check that links expose real destination URLs. |
| Inspect robots meta tags and HTTP X-Robots-Tag headers, including inherited server/CDN rules. Record conflicts, effective behavior, and any unintended noindex. |
| Compare declared canonical, redirects, internal links, sitemap URLs, and the search engine’s selected canonical where observable. Investigate unexpected differences. |
| Compare the original response with the relevant rendered view. Verify that service descriptions, people, jurisdictions, qualifications, links, and structured data survive rendering. |
| Check mobile views, language versions, regional pages, and alternate document formats. Preserve intended factual differences and investigate accidental duplication or misdirection. |
| Save the engine’s indexing report, last crawl date, selected canonical, and exclusion reason. Keep live inspection results separate from stored index information. |
| Record applicable snippet, preview, and AI-inclusion settings. Verify that their effective values match the firm’s policy. |
For non-HTML files, Google supports noindex through an X-Robots-Tag response header. Inspect the actual PDF or Word download; a correct landing page does not establish the file’s status.
A canonical is a preference signal. Apply it to duplicate or substantially similar versions, not merely related pages. Google supports a canonical HTTP Link header for supported non-HTML documents. Do not point a complete report at a short summary and assume they are equivalent.
Google can render JavaScript, but not all bots can. Prefer reliable delivery of essential content and test the actual route used by each relevant service.
For eligibility in Google’s documented Search generative AI features, a page must be indexed and snippet-eligible, and the site’s Search generative AI control must permit inclusion. Record the effective control, including inherited settings. Eligibility does not guarantee that a page will be selected or cited.
Sitemap submissions and indexing requests are actions, not proof of inclusion. Use URL Inspection and available engine reports; label search-query spot checks as incomplete observations.
E.3 Structured data
Generate markup from approved Part D facts and keep it consistent with the visible page. Maintain distinct identities for people, legal entities, practices, and network members.
Mapping template
[Page/template; entity ID; schema type/property; proposed value; visible source passage; Part D record/version; generation method; validator result; factual reviewer; publication date; change dependencies].
Suggested mappings
Page or subject | Candidate markup and factual checks |
Firm identity | Organization: approved name, legal identity, website, logo, and applicable contact details. Keep parent, subsidiary, and network relationships accurate. |
Professional profile | Person, with ProfilePage where appropriate: identity, current role, and organizational relationship. For Google’s ProfilePage feature, focus on a single person or organization affiliated with the website and follow its other requirements. |
Practice or service | Service: actual service, responsible provider, and supported coverage. Service geography does not establish professional authorization or office presence. |
Article or insight | Article, where applicable: title, identified author/publisher, and accurate publication and modification dates. |
Select types and properties that fit the page and the provider’s documented requirements. These mappings are starting points, not a requirement to apply every type.
Structured data checklist
- Inspect deployed markup, including anything generated by plugins or JavaScript. Resolve invalid syntax, conflicting duplicates, broken entity references, and outdated values.
- Check names, affiliations, locations, service boundaries, dates, and credentials against Part D. Preserve individual versus firm qualifications and current versus historical experience.
- Use sameAs only for verified identity references. Keep unsupported ratings, awards, credentials, and claims out of the markup.
- Record vocabulary validation, search-feature eligibility, and factual review as separate results.
- Retest affected pages when their templates or source facts change.
The Schema Markup Validator and Google’s Rich Results Test serve different purposes: general Schema.org validation and Google feature testing. A valid result does not establish that the facts are true or that a rich result will appear. Google’s structured data policies also require accurate, relevant representations of visible content.
Google’s generative AI guidance does not require special AI schema or llms.txt files. Assess optional formats only against a named consumer’s documented use and the effort needed to maintain them.
E.4 Document accessibility
Check both machine-readable content and human accessibility in the actual published download. Preserve the editable source so defects can be corrected before re-exporting.
Document verification record
[Asset ID/version; source file; download URL; format; intended audience; accessibility target and version/level; checker/version/settings; manual checks; reviewer/date; findings; owner; retest evidence].
Document checklist
Check | Evidence to retain |
| Text is selectable and extracts accurately. Verify OCR against the original, especially names, amounts, units, symbols, footnotes, and qualifications. |
| Word headings, lists, and table headers use native structure. Check heading order and meaningful relationships between table cells. |
| Inspect tags and logical reading order in the exported file. Check that headings, lists, tables, links, and alternatives survive conversion. |
| Provide useful alternatives for informative images and an accessible explanation or data equivalent for complex charts and technical diagrams. |
| Verify title, document language, descriptive links, and navigation suitable for the document’s length. |
| Test keyboard access and logical tab order. Check form labels, instructions, and understandable feedback where forms are present. |
| Review contrast, enlargement, and reflow where applicable. Preserve meaning without relying only on color. |
| Download the live file and compare it with the approved version. Check content, links, accessibility features, and any extraction restrictions. |
Microsoft’s Word guidance and Adobe’s PDF guidance support combining structural checks with manual review. Searchable text or a clean automated report establishes only the checks completed. Adobe specifically requires manual verification of logical reading order.
Provide an HTML companion where useful. If presented as an equivalent accessible alternative, verify that it meets the stated accessibility target, supplies the same information and functionality in the same language, remains equally current, and is accessibly reachable. A short summary is not an equivalent full report under W3C’s conforming-alternative criteria.
Record skipped and unresolved tests. Use the full applicable criteria and documented evaluation scope before making an accessibility conformance claim.
E.5 Verification and remediation
Shared evidence log
Create one entry per check and tested page or asset:
[Check ID; URL/asset/version; intended behavior; environment; timestamp; method/tool/version; actual result; retained evidence; status; interpretation limits; issue ID; owner; due date; retest result/date; reviewer].
Use Pass when evidence supports the agreed criterion; Fail when it contradicts it; Unresolved when evidence is inconclusive; Not checked when no test was completed; and Not applicable with a reason. A pass covers the tested scope and conditions.
Retain response headers, relevant HTML or rendered captures, crawler-log extracts, engine reports, validator output, and document-check findings as appropriate. Record sampling and coverage so one successful page cannot stand in for every template.
Release verification checklist
- Define scope. Select representative pages, downloads, environments, languages, and access policies. Identify the checks required for the proposed release.
- Capture a baseline. Save current configuration, observed behavior, applicable Part D versions, and known issues. Assign correction owners.
- Verify the change. Check the actual production response and published files after deployment. Recheck affected templates and linked content; staging behavior alone does not establish production behavior.
- Resolve findings. Correct failures and retest the affected behavior. Document approved exceptions, their scope, owner, and review date; retain unresolved items explicitly.
- Separate later outcomes. Record requests for recrawling or reindexing. Retain subsequent engine status in this log and AI-answer evidence in Part C, without treating a technical pass as proof of either outcome.
Issue and decision record
[Issue; affected checks/assets; business impact; priority; proposed fix; owner; target date; change reference; rollback approach where relevant; acceptance criterion; retest evidence; remaining limitations].
Prioritize according to the observed consequence: unintended public exposure, blocked priority content, misleading entity facts, or inability to use a document. Route findings to the responsible technical, content, or accessibility owner.
Release decision: [Ready / ready within documented limits / not ready]; [tested scope; unresolved items; approved exceptions; accountable owner; next review].
Keep technical release status separate from indexing or retrieval results that remain pending.
Illustrative verification record
Finding: A public report’s landing page is available, but its PDF carries an unintended noindex header.
Correction: The responsible owner changes the file-serving rule under the approved publication policy.
Retest: The actual download returns the approved file with the intended headers and passes the specified document checks.
Remaining observation: Index inclusion and later AI citation remain unconfirmed and are tracked separately.
Reopen relevant checks after hosting, firewall, CMS, template, document-export, or provider-policy changes. Feed approved factual changes through Part D and preserve the dates needed to interpret Part C’s monitoring history.
