/search-ready

Search readiness

Make a real site easier to crawl, index, understand, serve, cite, and share. Work from live behavior, repository intent, and search data as separate evidence classes.

Choose a mode

• Audit: diagnose live and repository issues without changing files.
• Implement: apply approved fixes and verify deployment behavior.
• Content opportunity: research current queries, competitors, and audience questions.
• Structured data: select, implement, and validate eligible markup.
• AI discovery: evaluate crawler policy, answer-ready content, entity clarity, and experimental aids.
• Maintenance: compare current state with prior evidence and define recurring checks.

Route by site type when relevant: SaaS/docs, editorial, commerce, local, or international. Do not use an equal-weight generic score across unlike sites.

Workflow

1. Confirm canonical production host, important routes/templates, audience, conversion action, locales, site type, and repository access. Inspect available Search Console/Bing, analytics, logs, prior audits, and deployment configuration before asking questions.
2. Fetch representative live URLs and inspect rendered HTML, source HTML where useful, headers, redirects, robots, sitemap/indexes, canonicals, hreflang, metadata, structured data, internal links, status behavior, and rendering dependencies.
3. Compare live behavior with repository intent. Label observed live behavior, source intent, search-platform data, and recommendation separately.
4. Inventory indexable route classes and assign each a search job. Diagnose duplicates, soft 404s, thin/orphaned pages, faceted/paginated states, accidental noindex, canonical conflicts, redirect chains, and sitemap coverage.
5. Prioritize blockers by likely impact on crawl, index, serve, comprehension, user experience, and business value—not character counts or checklist totals.
6. Research current result formats, branded/category queries, competitors, and source ecosystems when the task needs content or citation evidence. Treat rankings and snippets as time-sensitive.
7. Improve content around real questions and defensible claims. Preserve natural structure; do not force question headings, FAQs, word counts, or statistics at arbitrary intervals.
8. Add structured data only when it matches visible content, applicable schema, and current search-feature policies. Validate syntax and eligibility separately.
9. Treat AI-search practices by confidence: provider-documented crawler controls, standard accessible content, experimental conventions such as llms.txt, and unsupported speculation. Never promise rankings or citations.
10. Re-fetch the deployed result, run relevant validators and performance checks, compare route samples, and report remaining blockers and maintenance needs.

Load conditional references

• Read technical SEO for route sampling, diagnostics, implementation patterns, and validation.
• Read AI-search workflow only for answer engines, citations, crawler policy, or entity/content work.
• Read AI-search reference only for conditional schema, crawler, llms.txt, and outreach patterns.

This file controls prioritization, safety, output, and verification.

Output contract

Return mode-relevant sections:

• scope and evidence sources;
• prioritized findings with affected URLs/templates, severity, confidence, and fix;
• live-vs-repository discrepancies;
• route-level metadata/schema/indexation matrix;
• implemented changes with file paths;
• content opportunities grounded in current evidence;
• validator and deployed verification results;
• unresolved blockers and maintenance cadence.

Verify

• Representative templates and edge states were sampled, not just the homepage.
• Live response, rendered content, and repository intent are distinguished.
• Indexation claims use search-platform evidence when available and are otherwise qualified.
• Schema matches visible content and passes relevant validation.
• Redirects, canonicals, robots, sitemap, hreflang, status codes, and rendering agree.
• Performance claims identify lab versus field data.
• AI-search recommendations state evidence confidence and do not treat experimental conventions as guarantees.

Conditional AI-search patterns

Use only the pattern justified by the main workflow and current primary documentation.

Entity-oriented structured data

Prefer a small connected graph sourced from visible content over many disconnected blocks. Typical relationships can include:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Adapt types and properties to the actual entity. Do not add an offer, rating, price, author, or claim that is absent or unsupported on the page.

Optional llms.txt shape

If current evidence justifies the experiment:

# Product or documentation name

> Accurate definition for the intended audience.

## Documentation
- [Getting started](https://example.com/docs/start): Scope and contents.
- [Reference](https://example.com/docs/reference): Scope and contents.

## Policies or status
- [Security](https://example.com/security): Current security information.
- [Status](https://status.example.com/): Service status.

Use canonical, public, maintained URLs. A link description should describe the resource, not make a promotional claim.

Crawler policy record

Before editing robots.txt, record:

Generate rules from this record and existing wildcard groups. Verify syntax and live CDN response. Do not copy a frozen universal bot list.

Answer/content evidence table

Audience question
Current live answer and URL
Observed result/source landscape and date
Missing evidence or clarity
Proposed user-facing improvement
Schema/entity change, if justified
Measurement and limitation

Comparison content

Fair comparisons should state:

• audience/use case for each option;
• source and date for pricing/features;
• evaluation method and environment;
• limitations and conflicts of interest;
• where the competitor is a better fit.

Avoid unsourced feature checkmarks and pages generated only to capture competitor queries.

Outreach evidence record

Keep outside the send-ready message:

• article/resource URL and last meaningful update;
• author/editor role and contact source;
• submission/link policy;
• exact omission or factual update;
• proof the proposed resource adds;
• disclosure or commercial relationship.

AI-search evidence workflow

Use this reference only when the task includes answer engines, citations, AI crawler policy, or content/entity work. Conventional crawlability, accessible HTML, useful content, and authority remain the foundation.

Evidence confidence

Classify recommendations:

1. Provider documented: official crawler identity, robots behavior, publisher controls, or search documentation retrieved on a stated date.
2. Open standard/established web practice: semantic HTML, clear entities, canonical URLs, accessible content, source citation.
3. Experimental convention: community proposals such as llms.txt whose provider adoption may be unconfirmed.
4. Speculation: correlation studies, anecdotal prompt tests, or opaque ranking claims.

Do not present levels 3–4 as ranking or citation requirements.

Crawler policy

Identify the operator's goals separately for:

• search/retrieval visibility;
• user-initiated fetching;
• model training use;
• copyright, licensing, privacy, bandwidth, and competitive concerns.

Fetch current official crawler documentation before naming user agents or claiming effects. Record source and retrieval date. An explicit Allow is usually unnecessary when a valid broader rule already permits crawling; avoid bloating policy files without a reason.

Remember:

• robots rules are crawler-specific voluntary controls, not access control;
• similarly named crawlers can have different purposes;
• blocking a crawler does not establish when previously processed content disappears;
• CDN/WAF behavior and authenticated content can differ from robots.txt intent.

Content and entity analysis

For important audience questions:

1. inspect current result and answer formats;
2. identify recurring source types and primary evidence;
3. map whether the site has an accurate, accessible answer;
4. clarify the named entity, terminology, author/publisher, dates, and provenance;
5. improve the page for the user, not an arbitrary word-count formula;
6. cite original evidence for material factual claims.

Direct answers near relevant headings can improve comprehension, but not every section must begin with a fixed-length answer. Do not force FAQs, comparisons, statistics, or refresh cycles without audience need and maintainable evidence.

Structured data

Schema can clarify entities and content but does not guarantee AI citation. Add only markup that:

• matches visible content;
• uses the correct entity type and relationships;
• is maintained from the same source of truth;
• passes relevant validation;
• complies with current search-feature policies if rich-result eligibility is a goal.

Do not claim FAQPage, BlogPosting, HowTo, or BreadcrumbList is required for citation.

llms.txt

Treat llms.txt as an optional, low-cost experimental map when the site has stable canonical documentation and the team can maintain it. Before recommending it:

• verify the current proposal and provider adoption from primary sources;
• state that benefits are unconfirmed unless a provider documents support;
• curate canonical public links rather than duplicating a sitemap;
• avoid publishing secrets, private routes, unpublished pricing, or unsupported claims;
• verify HTTP status, content type, links, and freshness.

Citation and authority opportunities

Research current questions and the sources answer systems surface. Opportunities may include original data/methods, reference documentation, accurate definitions, transparent comparisons, expert authorship, and inclusion in credible maintained resources.

For outreach, verify the publication, article freshness, editor/author, submission policy, and real differentiator. Follow the cold-outreach skill when installed. Do not buy deceptive placements, manufacture reviews, or create fake consensus.

Measurement

Define what can actually be observed:

• server-log requests by documented crawler user agent/IP verification where available;
• referral traffic and tagged conversions;
• repeatable prompt samples with date, locale, account/model context, and citations;
• branded/category search data;
• third-party monitoring limitations.

Prompt tests are volatile samples, not a complete visibility score. Record uncertainty and avoid causal claims from before/after observations without controls.

Technical search diagnostics

Use this reference for technical audit, implementation, or verification after the main skill defines site type and scope. Do not calculate an equal-weight readiness score.

Contents

• Evidence and sampling
• Crawl and response behavior
• Indexing signals
• Rendering and content
• Structured data and previews
• Site-type branches
• Implementation and verification

Evidence and sampling

Build a representative matrix by route template and state:

Include homepage, important landing/content/product pages, dynamic detail pages, pagination/facets, locale variants, redirects, not-found/soft-404 behavior, and authenticated/private boundaries as relevant.

Evidence sources can include live HTTP/rendered behavior, repository/configuration, Search Console/Bing, analytics, server/CDN logs, structured-data validators, field performance, and lab tests. Record date and source; absence from a search result is not proof of non-indexation.

Crawl and response behavior

Check:

• status code, redirect target/count, and final canonical host/protocol;
• robots meta/header and robots.txt behavior for the actual user agent;
• sitemap/index availability, discoverable canonical URLs, truthful lastmod, and stale/redirect/error entries;
• internal-link discovery and orphan routes;
• URL parameter/facet/pagination behavior and crawl traps;
• soft 404s, server errors, timeouts, and CDN/WAF variation;
• response headers affecting indexing, caching, content type, or locale.

Do not assume every private route must be disallowed in robots. Robots exclusion does not provide access control and can prevent crawlers from seeing noindex; choose controls based on actual exposure.

Indexing signals

For each route class, reconcile:

• intended indexability;
• HTTP status and robots directives;
• canonical target and redirect behavior;
• sitemap inclusion;
• hreflang cluster where applicable;
• search-platform inspected/coverage state when available;
• duplication or near-duplication.

Canonical URLs are hints, not commands. Avoid adding self-canonicals mechanically before resolving host, parameter, pagination, syndication, and locale semantics.

Sitemap priority and changefreq are not substitutes for architecture or truthful modification dates. Follow current search-engine documentation for supported fields.

Rendering and content

Compare source and rendered HTML when JavaScript can affect:

• title, description, canonical, robots, hreflang, and structured data;
• primary content and headings;
• internal links and pagination;
• error/empty states;
• image/video content and alt/transcript support.

Use one clear page title and a logical heading structure, but do not fail pages solely for character counts, multiple H1 elements, absence of question headings, or arbitrary internal-link totals. Evaluate truncation risk, uniqueness, relevance, information scent, accessibility, and template duplication in context.

For performance, distinguish field data from lab data and name the tested device/network/template. Connect issues to crawl/render/user outcomes rather than treating framework patterns as proof of poor performance.

Structured data and previews

• Select schema types that match visible content and entity meaning.
• Check required/recommended properties against current official search-feature documentation.
• Validate JSON syntax/schema structure and search-feature eligibility separately.
• Do not add FAQ, HowTo, Product, Review, or Organization markup merely to earn a checklist point.
• Keep values consistent with visible content and canonical URLs.

For social previews, test the resolved metadata and image on representative routes. Verify absolute URL, fetchability, dimensions/file constraints from current platform documentation, fallback behavior, and localization.

Site-type branches

• SaaS/docs: docs discovery, integration/comparison pages, versioning, API references, status/changelog, subdomain strategy.
• Editorial: authorship, dates, archives, pagination, syndication, paywalls, news/article requirements.
• Commerce: product/variant/category URLs, availability/price consistency, merchant feeds, reviews, faceting, image search.
• Local: location entities, NAP consistency, location pages, business profiles, duplicate listings.
• International: locale URLs, hreflang reciprocity, language/region targeting, translation quality, fallback selectors.

Load only the branch relevant to the site.

Implementation and verification

Before editing, identify shared metadata/layout components and route-generation sources. Prefer fixing the template or data source over patching pages individually. Ask before making changes unless implementation was explicitly requested.

After change:

1. run repository tests/build/lint relevant to the files;
2. deploy or use an authorized preview;
3. fetch final and representative edge URLs;
4. verify headers, redirects, rendered HTML, robots, sitemap, canonical/hreflang, metadata, and schema;
5. run current official validators where applicable;
6. compare field/lab performance only with equivalent conditions;
7. record changes that require recrawl/reprocessing and avoid promising a timing outcome.