The Claude Skills Library

Purpose

Determines where crawl activity is being spent on [DOMAIN] and which URL classes are consuming requests without earning value.

Use when

Large sites (50k+ URLs), after a template change, or when new content takes weeks to be discovered.

Not for

Small brochure sites where crawl budget is not a constraint.

Inputs

• Server log sample or crawl stats export for [DATE RANGE]
• Full crawl export (URL, status, depth, indexability)
• Sitemap URL list

Method

1. Group every crawled URL into classes by path pattern and template.
2. Calculate share of crawl requests per class against share of indexable, valuable URLs.
3. Flag classes where crawl share exceeds value share by more than 2x.
4. Separate waste caused by parameters, pagination, and redirects from genuine content.
5. Rank remediation by requests reclaimed per unit of engineering effort.

Decision rules

• IF a URL class is non-indexable and heavily crawled → THEN recommend blocking or removing the entry points that generate it
• IF crawl share is concentrated on old but ranking content → THEN leave it alone and document why

Guardrails

• Never state a crawl frequency you have not seen in the supplied data
• Never recommend robots.txt blocking for URLs that carry backlinks or rankings
• Do not assume crawl budget is the cause of an indexing problem without evidence

Output

A crawl allocation table by URL class plus a ranked waste-reduction list with expected requests reclaimed.

Definition of done

• Every URL class in the export is assigned
• Each recommendation names the exact pattern to change
• Ranking and backlink exposure checked before any blocking advice

Purpose

Reviews robots.txt and meta robots directives for conflicts, over-blocking, and rules that no longer match the site structure.

Use when

Before a release, after a migration, or when indexing behaviour is unexplained.

Not for

Deciding what should rank — this skill only governs access and indexing directives.

Inputs

• Current robots.txt file
• Meta robots / X-Robots-Tag values from the crawl export
• List of URL patterns that must stay indexable

Method

1. Parse every robots.txt group and record which user agents each rule applies to.
2. Test the protected URL patterns against the rules and list any that are blocked.
3. Cross-check disallowed paths against meta robots values to find contradictions.
4. Identify rules referencing paths that no longer exist.
5. Produce a corrected file with a comment explaining each changed line.

Decision rules

• IF a URL is disallowed in robots.txt but carries a noindex tag → THEN flag it: the noindex cannot be read while the URL is blocked
• IF a rule blocks a directory containing indexable revenue pages → THEN mark it critical and stop for human confirmation

Guardrails

• Never propose a robots.txt change without showing the before and after lines
• Never block CSS or JS required for rendering
• Do not assume a wildcard behaves identically across all crawlers

Output

A conflict table (rule, affected pattern, risk level) and a rewritten robots.txt with inline change comments.

Definition of done

• Every protected pattern tested
• Every conflict has a stated resolution
• Rewritten file validated against the rule syntax

Purpose

Designs the sitemap structure for [DOMAIN]: how many files, split by what logic, and which URLs qualify for inclusion.

Use when

When sitemaps are missing, monolithic, or contain non-indexable URLs.

Not for

Diagnosing why an individual URL is not indexed.

Inputs

• Crawl export with status code and indexability
• Current sitemap files
• Priority content types and templates

Method

1. Define the inclusion rule: canonical, 200 status, indexable, and of standalone value.
2. Split URLs into sitemap files by template or section so coverage issues stay diagnosable.
3. List every URL currently included that fails the inclusion rule.
4. Specify the index sitemap and lastmod policy tied to real content changes.
5. Write the naming and update cadence for each file.

Decision rules

• IF a section has more than 40,000 qualifying URLs → THEN split it further by subcategory or date
• IF lastmod cannot be tied to a real content change → THEN recommend omitting the field rather than faking it

Guardrails

• Never include redirected, canonicalised, or noindexed URLs
• Never set lastmod to the generation date by default
• Do not treat sitemap inclusion as a ranking signal

Output

A sitemap architecture spec: file list, inclusion rules, split logic, lastmod policy, and an exclusion list.

Definition of done

• Inclusion rule stated explicitly
• Every current sitemap URL classified as keep or remove
• Split logic supports section-level diagnosis

Purpose

Compares three URL sets — sitemap, crawl, and indexed report — to find where discovery, crawling, and indexing diverge.

Use when

Monthly, and whenever indexed page counts move without a known cause.

Not for

Judging content quality — this skill reconciles sets, it does not evaluate pages.

Inputs

• Sitemap URL list
• Crawl export of internally linked URLs
• Index coverage export for [DOMAIN]

Method

1. Normalise all three lists (protocol, trailing slash, parameters) before comparison.
2. Build the four segments: in sitemap only, in crawl only, in both but not indexed, and indexed but in neither.
3. Sample each segment and identify the mechanical cause per group.
4. Attach a likely fix owner (content, engineering, or configuration) to each cause.
5. Report segment sizes and the top three causes by volume.

Decision rules

• IF URLs are indexed but absent from the sitemap and the crawl → THEN investigate orphan status and external discovery before removing anything
• IF URLs are in the sitemap but never crawled → THEN check internal link entry points before assuming a crawl budget issue

Guardrails

• Never estimate index coverage numbers that were not supplied
• Never delete URLs from a sitemap solely because they are not yet indexed
• Do not compare unnormalised URL strings

Output

A four-segment reconciliation table with counts, sampled examples, causes, and owners.

Definition of done

• All three lists normalised identically
• Every segment has at least three sampled examples
• Causes are mechanical, not speculative

Purpose

Finds canonical tags that contradict other signals: internal links, sitemaps, redirects, hreflang, or pagination.

Use when

After template changes, on faceted or parameterised sites, and before any migration.

Not for

Choosing which of two competing pages should win — use the cannibalisation skills for that.

Inputs

• Crawl export with canonical target per URL
• Sitemap URL list
• Redirect map if one exists

Method

1. Classify every URL as self-canonical, cross-canonical, or missing a canonical.
2. For cross-canonical URLs, verify the target returns 200 and is itself self-canonical.
3. Flag canonical targets that are redirected, noindexed, or absent from the sitemap.
4. Detect canonical chains and loops.
5. Group conflicts by template so fixes are made once at the source.

Decision rules

• IF a canonical points to a redirecting URL → THEN recommend pointing it at the final destination
• IF paginated pages canonicalise to page one → THEN flag it as content loss unless the deep items are reachable elsewhere

Guardrails

• Never change a canonical on a page ranking in the top three without explicit approval
• Never assume a canonical is honoured — treat it as a hint, not a directive
• Do not recommend canonicals between pages with materially different content

Output

A conflict register grouped by template, with the current target, correct target, and risk note per group.

Definition of done

• Every non-self-canonical URL verified
• Chains and loops listed separately
• Fixes expressed at template level

Purpose

Maps redirect chains, loops, and mixed-status hops, then produces a flattened redirect map.

Use when

After migrations, domain changes, or whenever hop counts grow over time.

Not for

Deciding whether a page should exist — this skill only handles routing.

Inputs

• Redirect export (source, target, status code)
• Crawl export of internal links pointing at redirected URLs
• List of URLs with external backlinks if available

Method

1. Trace each source to its final destination and record hop count and status types.
2. Flag chains over two hops, loops, and any 302 used for a permanent move.
3. Identify internal links still pointing at a redirected source.
4. Produce the flattened map: original source directly to final 200 destination.
5. Separate redirects that should be removed entirely from those that must be preserved for backlink equity.

Decision rules

• IF a chain ends on a 404 or a soft 404 → THEN flag it as broken and propose the nearest relevant live destination
• IF a redirect source has external backlinks → THEN keep the redirect permanently even if internal links are fixed

Guardrails

• Never remove a redirect that receives external links
• Never redirect to a page with no topical relationship to the source
• Do not mass-redirect deleted pages to the homepage

Output

A flattened redirect map plus two lists: internal links to update and redirects safe to retire.

Definition of done

• Every chain resolved to a final status
• Backlink exposure checked before retirement
• Internal link update list is specific to URL

Purpose

Classifies every non-200 response by cause and business impact, and assigns a resolution path.

Use when

Weekly on large sites, or after any deployment.

Not for

Judging content quality on pages that respond correctly.

Inputs

• Crawl export with status codes
• Internal link source list per broken URL
• Traffic or impression data per URL if available

Method

1. Group responses into 3xx, 4xx, 5xx and soft 404 behaviour.
2. For each 4xx, identify how the URL is still being discovered (internal link, sitemap, external link).
3. Prioritise by inbound internal links and prior search demand.
4. Escalate all 5xx responses as an availability issue before any SEO recommendation.
5. Assign each URL one of four paths: fix, redirect, remove entry points, or leave to expire.

Decision rules

• IF a 404 has external links or prior search demand → THEN recommend a redirect to the closest live equivalent
• IF a 404 has no links and no demand → THEN recommend removing the entry point rather than adding a redirect

Guardrails

• Never invent traffic history for a broken URL
• Never redirect purely to make a report look clean
• Do not treat intentional 410 responses as errors

Output

A prioritised status code register with cause, discovery source, and assigned resolution path.

Definition of done

• All 5xx escalated first
• Every 4xx has a discovery source
• Resolution path is one of the four defined options

Purpose

Identifies indexed URLs that provide no search value and specifies how each should be removed from the index.

Use when

When indexed URL count far exceeds the number of pages that should rank.

Not for

Removing underperforming but strategically important content.

Inputs

• Index coverage export
• Crawl export with template classification
• Impression or click data per URL for [DATE RANGE]

Method

1. Classify indexed URLs by template and identify machine-generated classes.
2. For each class, check impressions, clicks, and internal link volume.
3. Separate zero-value classes from low-value-but-earning classes.
4. Choose the correct removal mechanism per class: noindex, canonical, 410, or blocked entry points.
5. Sequence the changes so removals happen before access is blocked.

Decision rules

• IF a URL class has zero impressions and zero backlinks over 90 days → THEN recommend noindex, then removal of internal entry points
• IF a class has small but consistent long-tail impressions → THEN keep it and improve it instead of removing it

Guardrails

• Never block a URL in robots.txt before its noindex has been processed
• Never remove URLs with backlinks without a redirect plan
• Do not assume low clicks means zero value without checking impressions and assisted paths

Output

A removal plan by URL class: mechanism, sequence, expected index reduction, and rollback note.

Definition of done

• Every class has evidence attached
• Mechanism and order specified
• Rollback path documented

Purpose

Documents the site's indexing rules as a single reference: which templates are indexable, which are not, and why.

Use when

Once per site, then updated whenever a new template ships.

Not for

One-off debugging of a single URL.

Inputs

• Template inventory
• Current directives per template
• Business rules on what must never be indexed

Method

1. List every template and its current indexability state.
2. Record the mechanism enforcing that state and where it lives in the stack.
3. Mark templates where the intended state and the actual state differ.
4. Define the required state for each template with a one-line justification.
5. Write the rule set in a form engineering can implement and test.

Decision rules

• IF intended and actual states differ → THEN raise a defect with the exact enforcing mechanism named
• IF a template has no defined intended state → THEN stop and request a decision rather than choosing one

Guardrails

• Never guess the business intent behind an existing directive
• Never document a rule you have not verified in the crawl data
• Do not include page-level exceptions in a template-level document

Output

An indexability rule matrix: template, intended state, actual state, enforcing mechanism, and defect flag.

Definition of done

• Every template covered
• Each rule has a named mechanism
• All mismatches raised as defects

Purpose

Compares raw HTML against rendered HTML to determine which SEO-critical elements depend on client-side execution.

Use when

On JS frameworks, single-page apps, or after a front-end rebuild.

Not for

Measuring page speed — use the Core Web Vitals skills for that.

Inputs

• Raw HTML source for sample URLs per template
• Rendered DOM output for the same URLs
• List of SEO-critical elements to verify

Method

1. For each template, compare raw and rendered output for title, headings, body copy, canonical, links, and structured data.
2. Record every element present only after rendering.
3. Check whether internal links exist as crawlable anchors in the raw HTML.
4. Identify content behind interaction (tabs, accordions, infinite scroll) and whether it exists in the DOM.
5. Rate each template as safe, at risk, or blocking.

Decision rules

• IF primary body content appears only after rendering → THEN rate the template at risk and recommend server-side rendering for that content
• IF navigation links are generated by script without anchors → THEN rate it blocking and specify anchor-based fallback links

Guardrails

• Never conclude a page renders correctly from a screenshot alone
• Never assume all crawlers execute JavaScript identically
• Do not recommend a rendering strategy change without naming the affected elements

Output

A per-template rendering matrix with element-level presence in raw versus rendered HTML and a risk rating.

Definition of done

• Every template sampled
• All critical elements checked in both states
• Risk ratings justified by named elements

Purpose

Verifies that the mobile experience contains the same indexable content, links, and metadata as the desktop version.

Use when

On separate mobile builds, adaptive templates, or after a responsive redesign.

Not for

Visual design review.

Inputs

• Mobile and desktop HTML for the same sample URLs
• Structured data output for both
• List of templates with device-specific behaviour

Method

1. Diff body content, headings, and internal links between the two versions.
2. Compare titles, meta descriptions, canonicals, and hreflang values.
3. Compare structured data blocks and their property values.
4. Flag content hidden or removed on mobile that carries ranking value.
5. Summarise parity gaps by template and severity.

Decision rules

• IF mobile omits content that ranks on desktop → THEN flag it as a critical parity gap
• IF content is collapsed but present in the mobile DOM → THEN record it as acceptable and note the interaction pattern

Guardrails

• Never assume responsive design guarantees parity
• Never compare pages captured at different dates
• Do not treat layout differences as content differences

Output

A parity gap table by template: element, desktop state, mobile state, severity.

Definition of done

• Both versions captured on the same date
• All critical elements diffed
• Severity assigned per gap

Purpose

Finds internal near-duplicate pages and determines whether each cluster needs consolidation, differentiation, or a canonical.

Use when

On large catalogues, location pages, or programmatically generated content.

Not for

Comparing your content against external sites.

Inputs

• Crawl export with body text or content hashes
• URL, title, and H1 per page
• Performance data per URL if available

Method

1. Cluster URLs by content similarity and by title/H1 similarity separately.
2. For each cluster, identify the strongest performer using supplied performance data.
3. Determine whether the pages serve different intents or the same one.
4. Assign each cluster one action: consolidate, differentiate, canonicalise, or leave.
5. Specify what unique content each retained page must gain.

Decision rules

• IF pages are near-identical and target the same query → THEN recommend consolidation into the strongest performer
• IF pages are similar but serve genuinely different intents → THEN recommend differentiation and keep both

Guardrails

• Never consolidate pages without checking backlinks and current rankings
• Never rely on title similarity alone to declare duplication
• Do not delete duplicates — redirect or canonicalise them

Output

A duplicate cluster register: member URLs, similarity basis, chosen action, and the retained URL.

Definition of done

• Every cluster has a named retained URL
• Action justified by intent and performance
• Backlink check recorded per cluster

Purpose

Audits how paginated series expose their items to crawlers and whether deep items remain reachable.

Use when

On blogs, catalogues, and archives with multi-page series.

Not for

Deciding how many items should appear per page from a UX standpoint.

Inputs

• Sample paginated series URLs
• Crawl export showing depth and discovery path for deep items
• Current canonical and indexability of paginated pages

Method

1. Map how page two onward is linked and whether links exist in raw HTML.
2. Check whether items on deep pages have any other internal discovery path.
3. Review canonical and indexability treatment across the series.
4. Measure click depth of the deepest items.
5. Recommend a pattern: indexable series, view-all, or improved category entry points.

Decision rules

• IF deep items are only reachable through pagination beyond page five → THEN recommend additional entry points such as filtered hubs
• IF paginated pages canonicalise to page one → THEN recommend self-canonical pages to preserve item discovery

Guardrails

• Never noindex paginated pages while they remain the only discovery path
• Never rely on infinite scroll without crawlable pagination links
• Do not assume item pages are indexed because the series is

Output

A pagination pattern report per series with discovery depth, current treatment, and a recommended pattern.

Definition of done

• Deepest item depth measured
• Alternative discovery paths identified
• Recommended pattern specified per series

Purpose

Defines which filter combinations may be crawled and indexed, and which must be blocked at the source.

Use when

On e-commerce or directory sites where filters generate URLs.

Not for

Designing the filter interface itself.

Inputs

• List of facet parameters and their value counts
• Sample generated URLs
• Search demand evidence for facet combinations

Method

1. Enumerate facets and calculate the theoretical URL space they create.
2. Identify facet combinations with genuine external search demand.
3. Define three tiers: indexable, crawlable but not indexed, and blocked.
4. Specify the enforcement mechanism per tier and where it applies.
5. Define how new facet values are handled by default.

Decision rules

• IF a facet combination has demonstrated search demand → THEN promote it to indexable with a static, linkable URL
• IF a facet combination exists only for on-site filtering → THEN keep it out of crawlable links entirely

Guardrails

• Never open a facet to indexing without demand evidence
• Never rely on canonical tags alone to control facet crawling
• Do not block facets that are currently ranking without a migration plan

Output

A facet governance table: parameter, tier, mechanism, and default rule for new values.

Definition of done

• Every facet assigned a tier
• Demand evidence attached to indexable facets
• Default rule for new values defined

Purpose

Reduces click depth for pages that carry business value but sit too far from the entry points.

Use when

When valuable pages are more than three clicks deep.

Not for

Choosing internal link anchors — the internal linking skills handle that.

Inputs

• Crawl export with click depth per URL
• Business value or revenue tier per page type
• Current navigation and hub structure

Method

1. Plot depth distribution and identify value-tier pages beyond depth three.
2. Trace the shortest existing path to each deep page.
3. Identify which hub, category, or navigation change would shorten it most.
4. Group pages that can be lifted by the same structural change.
5. Sequence changes by number of pages improved per change.

Decision rules

• IF many valuable pages share one deep parent → THEN fix the parent's exposure instead of linking each page individually
• IF a page is deep because it is low value → THEN leave the depth and record the decision

Guardrails

• Never add navigation links purely to reduce depth numbers
• Never flatten hierarchy in a way that breaks topical grouping
• Do not treat depth as a ranking factor — treat it as a discovery and priority signal

Output

A depth reduction plan: structural change, pages improved, new expected depth, and effort estimate.

Definition of done

• Value tier applied before prioritising
• Changes grouped by shared parent
• Expected new depth stated per group

Purpose

Turns raw server logs into a picture of how search crawlers actually behave on [DOMAIN].

Use when

Monthly on large sites, and after migrations or major structural changes.

Not for

Measuring user traffic or conversions.

Inputs

• Server log file for [DATE RANGE]
• Crawl export for URL classification
• List of verified crawler user agents

Method

1. Filter to verified search crawler requests and discard spoofed agents.
2. Aggregate requests by URL class, status code, and day.
3. Identify never-crawled indexable URLs and over-crawled low-value URLs.
4. Detect crawl pattern breaks: sudden drops, spikes, or shifts between sections.
5. Correlate pattern breaks with known deployment or content dates only when those dates are supplied.

Decision rules

• IF indexable priority URLs show no crawl requests in the period → THEN investigate internal linking and sitemap inclusion first
• IF crawl requests spike on error responses → THEN escalate as a server or configuration issue

Guardrails

• Never treat unverified user agents as search crawlers
• Never claim a correlation with a deployment without a supplied deployment date
• Do not extrapolate crawl behaviour from a sample period shorter than 14 days

Output

A crawl behaviour report: class-level request distribution, uncrawled priority URLs, and pattern breaks with dates.

Definition of done

• Crawler verification applied
• Uncrawled priority list produced
• Every pattern break has a date and observed magnitude

Purpose

Converts field and lab performance data into a small set of engineering fixes ranked by affected page volume.

Use when

Quarterly, or when field data shows a threshold breach on a key template.

Not for

Rewriting front-end code — this skill produces the diagnosis and the brief.

Inputs

• Field data by URL group
• Lab diagnostics for representative URLs
• Template-to-URL mapping

Method

1. Group URLs by template and attach field metrics to each group.
2. For failing groups, identify the dominant contributing element from lab diagnostics.
3. Determine whether the cause is template-level or content-level.
4. Estimate how many URLs each fix would improve.
5. Write one implementation brief per fix, ordered by URLs improved.

Decision rules

• IF a metric fails on one template only → THEN treat it as a template defect and brief engineering on that template
• IF failures follow specific content, such as heavy embeds → THEN treat it as an editorial rule, not an engineering fix

Guardrails

• Never report lab data as if it were field data
• Never promise ranking improvements from performance work
• Do not aggregate metrics across templates with different layouts

Output

A triage table by template with failing metric, dominant cause, URLs affected, and a linked implementation brief.

Definition of done

• Field and lab data kept separate
• Cause named per failing template
• Fixes ranked by URLs improved

Purpose

Identifies scripts, styles, and third-party tags delaying the first meaningful render, and proposes a loading policy.

Use when

When performance triage points to resource loading rather than layout or server time.

Not for

Deciding which marketing tags the business needs.

Inputs

• Resource waterfall for representative URLs
• Third-party tag inventory with owners
• Template-to-URL mapping

Method

1. List every blocking resource by size, origin, and position in the critical path.
2. Separate first-party from third-party and note the owner of each tag.
3. Classify each resource: required for render, deferrable, or removable.
4. Quantify the render path saving per resource where the waterfall supports it.
5. Produce a loading policy: what loads inline, deferred, async, or on interaction.

Decision rules

• IF a third-party tag has no named owner → THEN flag it for removal review rather than optimisation
• IF a resource is required for above-the-fold layout → THEN keep it blocking and optimise its size instead

Guardrails

• Never recommend removing a tag without identifying its business function
• Never defer resources that control above-the-fold layout
• Do not present estimated savings as measured savings

Output

A resource policy table: resource, owner, classification, loading strategy, and expected effect.

Definition of done

• Every blocking resource classified
• Third-party owners identified or flagged
• Loading strategy specified per resource

Purpose

Verifies protocol consistency across the site and finds insecure references that undermine it.

Use when

After migrations, CDN changes, or certificate renewals.

Not for

Certificate procurement or infrastructure configuration.

Inputs

• Crawl export including resource URLs
• Certificate details and expiry
• List of subdomains in use

Method

1. Confirm every indexable URL resolves over HTTPS with a valid certificate.
2. Find pages loading insecure resources and record the resource origin.
3. Check that HTTP versions redirect once, permanently, to the HTTPS equivalent.
4. Verify canonicals, hreflang, and sitemap entries all use the secure protocol.
5. List subdomains missing coverage and note certificate expiry dates.

Decision rules

• IF a page loads insecure third-party resources → THEN identify the source template and fix it there
• IF HTTP to HTTPS redirects pass through an intermediate hop → THEN recommend flattening to a single hop

Guardrails

• Never assume a redirect exists without testing the HTTP version
• Never report certificate validity without the supplied certificate data
• Do not overlook subdomains and asset domains

Output

A protocol audit: insecure resource list by template, redirect behaviour, signal consistency, and certificate coverage.

Definition of done

• All subdomains checked
• Every insecure resource traced to a template
• Redirect hop count recorded

Purpose

Provides the pre-launch and post-launch validation sequence for a migration, with hard stop conditions.

Use when

Before and after any domain change, replatform, or large-scale URL restructure.

Not for

Deciding whether to migrate — this skill validates execution.

Inputs

• Old URL inventory with performance and backlink data
• New URL inventory
• Proposed redirect map and launch date

Method

1. Verify every old URL with value maps to exactly one new URL, and list unmapped ones.
2. Check the new environment for indexability, canonicals, hreflang, and structured data before launch.
3. Define hard stop conditions that block launch if unmet.
4. Specify the post-launch checks for day one, week one, and week four with what to measure.
5. Define the rollback trigger and who owns the decision.

Decision rules

• IF a high-value old URL has no mapped destination → THEN treat it as a hard stop until mapped
• IF post-launch checks show sustained loss beyond the agreed threshold → THEN trigger the documented rollback review, not ad hoc fixes

Guardrails

• Never launch with unmapped URLs that carry backlinks or rankings
• Never compare post-launch performance across different date range lengths
• Do not attribute every post-launch change to the migration without evidence

Output

A migration validation pack: mapping gaps, pre-launch checklist, hard stops, post-launch schedule, and rollback trigger.

Definition of done

• Every valuable old URL mapped or explicitly retired
• Hard stops agreed before launch
• Post-launch measurement dates fixed in advance

Purpose

Validates international targeting annotations for reciprocity, coverage, and conflicts with canonicals.

Use when

On multi-language or multi-market sites, and after adding a market.

Not for

Deciding which markets to enter or which languages to translate.

Inputs

• Hreflang annotations per URL
• Market and language matrix
• Canonical values per URL

Method

1. Verify every annotation returns a reciprocal reference from its target.
2. Check language and region codes against valid values.
3. Confirm each annotated URL is self-referencing and self-canonical.
4. Find market pages missing from the cluster and clusters missing an x-default.
5. Group errors by cluster and template.

Decision rules

• IF a target URL does not reference back → THEN flag the cluster as invalid rather than partially valid
• IF hreflang points to a canonicalised URL → THEN flag the conflict and recommend annotating canonical URLs only

Guardrails

• Never mix language-only and language-region codes inconsistently within a cluster
• Never annotate URLs that are redirected or noindexed
• Do not assume a missing market is an error without checking the market matrix

Output

A cluster validation report: cluster, missing reciprocals, invalid codes, canonical conflicts, and coverage gaps.

Definition of done

• Reciprocity verified in both directions
• Codes validated against the market matrix
• Errors grouped by template

Purpose

Checks deployed structured data for syntax validity, required properties, and agreement with visible page content.

Use when

After template changes, and quarterly across key templates.

Not for

Choosing which new schema types to deploy — use the corresponding skill for that.

Inputs

• Extracted structured data
• Visible page content for the same URLs
• List of deployed schema types

Method

1. Validate syntax of every deployed structured data block (JSON-LD, microdata, RDFa).
2. Check required and recommended properties for each schema type used.
3. Verify the structured data agrees with the visible page content.
4. Flag missing, invalid, or mismatched properties grouped by template.
5. Produce a per-template fix list ordered by affected URL volume.

Decision rules

• IF structured data describes content not visible on the page → THEN flag it as a mismatch and remove or correct it
• IF a required property is missing across an entire template → THEN raise it as a template defect, not a page-by-page fix

Guardrails

• Never recommend schema that does not match the page's actual content
• Never mark a page valid from syntax alone without checking required properties
• Do not report rich result status without Search Console evidence

Output

A structured data error register grouped by template: error type, affected URLs, required fix.

Definition of done

• Every template with structured data sampled
• Syntax, required properties and content agreement all checked
• Errors grouped by template with fixes stated

Purpose

Tracks technical error classes over time so that structural regressions are separated from routine noise.

Use when

Weekly, using consecutive crawl or coverage exports.

Not for

Diagnosing a single URL's problem in depth.

Inputs

• Current and previous crawl or coverage exports
• Deployment log with dates if available
• Error class definitions used previously

Method

1. Normalise both exports and compute error counts per class and per template.
2. Calculate period-over-period change and flag classes exceeding the agreed variance band.
3. Identify new error classes not present in the prior period.
4. Check whether flagged changes concentrate in one template or spread site-wide.
5. Report only the changes that pass the variance threshold.

Decision rules

• IF an error class grows for two consecutive periods → THEN escalate it as a regression rather than noise
• IF a spike coincides with a supplied deployment date → THEN note the coincidence as a hypothesis, not a proven cause

Guardrails

• Never report every fluctuation as a problem
• Never claim causation from timing alone
• Do not compare exports generated with different crawl settings

Output

A trend report: error class, previous count, current count, change, template concentration, and escalation status.

Definition of done

• Variance threshold applied
• Crawl settings confirmed identical
• Only threshold-breaching changes escalated

Purpose

Detects non-production environments and internal URLs exposed to crawlers or search results.

Use when

Monthly, and immediately after any new environment is created.

Not for

Access control and infrastructure security policy.

Inputs

• List of known environments and hostnames
• Crawl export including external link targets
• Index coverage export

Method

1. Check known staging hostnames for indexability and public accessibility.
2. Search the production crawl for links pointing to non-production hosts.
3. Look for production pages referencing staging asset paths.
4. Verify robots and authentication treatment per environment.
5. Escalate any exposed environment before recommending SEO fixes.

Decision rules

• IF a staging environment is publicly accessible and indexable → THEN escalate immediately and recommend authentication, not robots.txt
• IF production pages link to staging assets → THEN raise a build configuration defect

Guardrails

• Never rely on robots.txt as the protection mechanism for private environments
• Never publish discovered staging URLs in a widely shared document
• Do not attempt to access environments you are not authorised to reach

Output

An exposure register: environment, accessibility, indexing state, referencing production pages, and escalation status.

Definition of done

• Every known environment checked
• Production references listed
• Escalations raised before SEO recommendations

Purpose

Turns a small set of seed terms for [PRIMARY TOPIC] into a structured expansion set organised by modifier type.

Use when

At the start of a new topic, market, or product line.

Not for

Final prioritisation; this skill produces candidates, not a plan.

Inputs

• 3-10 seed terms
• Product and category vocabulary from SEO_CONTEXT
• Customer language sources (support tickets, sales calls, reviews)

Method

1. Break each seed into its head noun, qualifier, and implied job.
2. Expand along five axes: problem, solution, comparison, use case, and audience.
3. Add vocabulary variants taken from customer language sources, not invented synonyms.
4. Mark each candidate with the axis it came from and the source of the wording.
5. Remove candidates outside the excluded topics list.

Decision rules

• IF a candidate uses vocabulary the business never uses → THEN keep it only if a customer source supports it
• IF a candidate matches an excluded topic → THEN drop it and record the exclusion

Guardrails

• Never invent search volume for any candidate
• Never present machine-generated variants as verified customer language
• Do not include competitor brand terms without a stated strategy

Output

An expansion table: candidate term, axis, source of wording, and inclusion status.

Definition of done

• Every candidate has a source
• All five axes covered
• Exclusions applied and listed

Purpose

Assigns each query a documented intent class and the page type required to serve it.

Use when

Before writing briefs or mapping queries to URLs.

Not for

Estimating traffic potential.

Inputs

• Query list
• SERP observations or supplied SERP data
• Site page type inventory

Method

1. Classify each query as informational, commercial, transactional, or navigational.
2. Record the evidence used: SERP composition, query wording, or supplied data.
3. Map each intent class to the page type your site uses to serve it.
4. Flag mixed-intent queries where the SERP shows more than one dominant format.
5. List queries where your existing page type does not match the intent.

Decision rules

• IF the SERP shows two dominant formats → THEN label the query mixed intent and note which format leads
• IF no SERP evidence is available → THEN mark the classification provisional and state the assumption

Guardrails

• Never classify intent from the query string alone when SERP data is available
• Never assume commercial intent because a term includes a product noun
• Do not present provisional classifications as verified

Output

An intent table: query, class, evidence, required page type, current page type match.

Definition of done

• Every query has evidence recorded
• Mixed-intent queries flagged
• Mismatches listed separately

Purpose

Groups queries into clusters that a single page can realistically serve.

Use when

After expansion and intent classification, before content planning.

Not for

Deciding publication order; use the prioritisation skills for that.

Inputs

• Classified query list with intent
• SERP overlap data if available
• Existing URL to query mapping

Method

1. Group queries by shared intent and shared answer, not by keyword similarity.
2. Split any group whose members require different page types.
3. Name each cluster by the job it does for the reader.
4. Designate one primary query and list secondary queries per cluster.
5. Map each cluster to an existing URL or mark it as a gap.

Decision rules

• IF two queries share wording but need different pages → THEN separate them into distinct clusters
• IF a cluster maps to more than one existing URL → THEN hand it to the cannibalisation skills before creating content

Guardrails

• Never build clusters from string similarity alone
• Never assign one cluster to two URLs without a documented reason
• Do not invent SERP overlap data

Output

A cluster table: cluster name, primary query, secondary queries, intent, mapped URL or gap flag.

Definition of done

• Every query belongs to exactly one cluster
• Each cluster has one primary query
• URL mapping or gap flag applied

Purpose

Designs the hierarchy above the query clusters: which pillar owns which clusters and how they relate.

Use when

When planning a new topic area or restructuring an existing one.

Not for

Writing the content itself.

Inputs

• Query cluster list
• Existing site structure
• Business priority per topic

Method

1. Group clusters into topics that share a subject and an audience.
2. Assign each topic one pillar page and define its scope boundary.
3. Order clusters within each topic from foundational to advanced.
4. Define the required link relationship between pillar and supporting pages.
5. Flag clusters that belong to more than one topic and assign a single owner.

Decision rules

• IF a cluster fits two pillars → THEN assign it to the pillar closest to the buying decision and cross-link the other
• IF a pillar would need to cover more than eight clusters → THEN split the topic

Guardrails

• Never create a pillar for a topic with no supporting cluster demand
• Never let two pillars claim the same primary query
• Do not design hierarchy that conflicts with the existing URL structure without saying so

Output

A topic architecture map: topic, pillar page, owned clusters in order, cross-links, and structural conflicts.

Definition of done

• Every cluster assigned to exactly one pillar
• Pillar scope boundaries stated
• Structural conflicts listed

Purpose

Maps clusters to stages of the buying process so coverage gaps become visible by stage, not just by topic.

Use when

When traffic exists but pipeline does not, or before planning a quarter.

Not for

Attribution modelling.

Inputs

• Cluster list with intent
• ICP definition and buyer problems from SEO_CONTEXT
• Existing page inventory by stage

Method

1. Define the stages used by this business in its own language.
2. Assign each cluster to one stage using the query wording and intent evidence.
3. Count existing pages per stage and identify the thinnest stage.
4. Identify stages where competitors are present and you are absent.
5. Recommend the next three clusters to build, one per weakest stage.

Decision rules

• IF a stage has demand but no page → THEN flag it as a priority gap
• IF a cluster could sit in two stages → THEN assign it to the later stage and note the earlier fit

Guardrails

• Never assume stage from search volume
• Never claim a revenue effect for a stage without supplied conversion data
• Do not use generic funnel labels that the business does not use

Output

A stage coverage map: stage, clusters, existing pages, gaps, and the three highest-priority builds.

Definition of done

• Stages named in the company's language
• Every cluster assigned a stage
• Gaps ranked

Purpose

Finds query clusters where [COMPETITORS] have coverage and [DOMAIN] does not, filtered by strategic fit.

Use when

Quarterly, and before planning a new content cycle.

Not for

Copying competitor content structure.

Inputs

• Competitor URL and query exports
• Own query to URL mapping
• Strategic exclusions from SEO_CONTEXT

Method

1. Normalise both query sets and identify queries covered by competitors only.
2. Cluster the gap queries rather than listing them individually.
3. Filter out clusters outside the excluded topics or the ICP.
4. Assess whether each remaining cluster is winnable given existing topical coverage.
5. Rank surviving clusters by strategic fit and proximity to revenue.

Decision rules

• IF a gap cluster sits outside the ICP → THEN drop it regardless of its size
• IF multiple competitors cover a cluster and you have adjacent authority → THEN raise its priority

Guardrails

• Never assume a competitor ranks for a term without supplied evidence
• Never treat a large gap as an opportunity if it fails the ICP filter
• Do not invent competitor traffic figures

Output

A ranked gap list: cluster, competitors present, strategic fit, winnability note, and priority.

Definition of done

• Gaps clustered, not listed raw
• ICP filter applied
• Winnability justified per cluster

Purpose

Separates branded from non-branded demand so that performance analysis is not distorted by brand growth.

Use when

Before any performance review or forecast.

Not for

Judging brand strength.

Inputs

• Query list or performance export
• Brand terms and misspellings from SEO_CONTEXT
• Competitor brand terms

Method

1. Build the match rules for own brand, competitor brand, and product-name terms.
2. Apply the rules and place every query in exactly one bucket.
3. Review the unmatched bucket manually and extend the rules.
4. Report each bucket separately with its own totals.
5. Save the rule set so the split is reproducible next period.

Decision rules

• IF a product name is also a generic term → THEN create a specific rule and document the ambiguity
• IF competitor brand terms appear in your data → THEN report them as a third bucket, not non-branded

Guardrails

• Never report blended totals without the split
• Never fold competitor brand queries into non-branded performance
• Do not change the rule set between periods without stating it

Output

Three separated query sets with totals, an ambiguity list, and the saved rule set.

Definition of done

• Every query bucketed
• Ambiguities documented
• Rule set saved for reuse

Purpose

Surfaces specific, low-competition queries that existing pages could serve with small additions.

Use when

When you need results without publishing new pages.

Not for

Building new pillar content.

Inputs

• Query export including low-impression queries
• Current page to query mapping
• Page content for the mapped URLs

Method

1. Extract queries with impressions but weak position that already map to an existing URL.
2. Group them by the page that nearly serves them.
3. For each page, identify what the query asks that the page does not answer.
4. Specify the smallest addition that would serve the query: a section, a definition, or a table row.
5. Rank pages by number of queries unlocked per page.

Decision rules

• IF a page nearly serves several related queries → THEN recommend one section covering the group, not one per query
• IF a query needs a different page type → THEN move it to the content planning skills instead

Guardrails

• Never invent impression or position figures
• Never recommend adding thin paragraphs for each query variation
• Do not target queries whose intent the page cannot honestly satisfy

Output

A per-page opportunity list: page, unlocked queries, missing answer, and the specific addition required.

Definition of done

• Every opportunity tied to a real query in the export
• Additions specified concretely
• Pages ranked by queries unlocked

Purpose

Collects the real questions your audience asks and formats them for direct use in content and FAQ blocks.

Use when

When building briefs, FAQ sections, or answer-first content.

Not for

Keyword volume analysis.

Inputs

• Customer-facing sources: support tickets, sales calls, reviews, community threads
• Query export containing question phrasings
• Buyer language notes from SEO_CONTEXT

Method

1. Extract questions verbatim from each source and record the source type.
2. Group duplicates by meaning while keeping the most common phrasing.
3. Separate pre-purchase, evaluation, and post-purchase questions.
4. Mark questions that current content answers and those it does not.
5. Rank unanswered questions by frequency across sources.

Decision rules

• IF a question appears in both support and search data → THEN raise its priority; it affects acquisition and retention
• IF a question implies a product limitation → THEN route it to the product or support owner, not only to content

Guardrails

• Never rewrite customer phrasing into marketing language during collection
• Never invent questions to fill a section
• Do not include questions the business cannot answer truthfully

Output

A question bank: question, source type, frequency, stage, answered or unanswered.

Definition of done

• Every question traceable to a source
• Answered status verified against live pages
• Ranked list of unanswered questions produced

Purpose

Translates supplied difficulty metrics into a realistic assessment for this specific site.

Use when

Before committing resources to a competitive cluster.

Not for

Producing difficulty scores; the tool supplies those.

Inputs

• Difficulty metrics from your chosen tool
• SERP composition for the target queries
• Your site's authority and topical coverage evidence

Method

1. Record the supplied difficulty figure and the tool that produced it.
2. Describe the actual SERP: page types, publishers, and content depth.
3. Compare your existing topical coverage against the ranking pages.
4. State what would have to be true for your page to compete.
5. Give a verdict: pursue now, pursue after supporting content, or skip.

Decision rules

• IF the SERP is dominated by page types you cannot produce → THEN recommend skipping regardless of the difficulty score
• IF difficulty is high but your topical coverage is strong → THEN recommend pursuing with a supporting content requirement

Guardrails

• Never treat a difficulty score from one tool as an absolute standard
• Never predict a ranking position
• Do not ignore SERP composition in favour of a single number

Output

A verdict per cluster: supplied score, SERP description, coverage comparison, requirements, and recommendation.

Definition of done

• Tool source named
• SERP described, not assumed
• Requirements stated before the verdict

Purpose

Scores clusters on a consistent model so planning debates are about weights, not opinions.

Use when

Before each planning cycle.

Not for

One-off decisions about a single page.

Inputs

• Cluster list with available demand data
• Business priority weights from SEO_CONTEXT
• Current coverage status per cluster

Method

1. Define the scoring dimensions and their weights before scoring anything.
2. Score each cluster on demand, business fit, competitive feasibility, and effort.
3. Note the evidence supporting each score, or mark it as an estimate.
4. Produce the ranked list and identify where estimates change the order.
5. Record the weights used so the next cycle is comparable.

Decision rules

• IF a score relies on an estimate that changes the ranking → THEN flag the cluster as decision-sensitive and request data
• IF two clusters score within one point → THEN break the tie with business fit, not demand

Guardrails

• Never present estimates as measured data
• Never change weights mid-cycle without recording it
• Do not score effort without input from the team who will do the work

Output

A scored and ranked cluster table with weights, evidence markers, and decision-sensitive flags.

Definition of done

• Weights fixed before scoring
• Estimates marked
• Ranked output reproducible

Purpose

Maps the concepts, attributes, and adjacent subjects that a comprehensive page on [PRIMARY TOPIC] should address.

Use when

When writing briefs for competitive or technical topics.

Not for

Keyword density optimisation.

Inputs

• Target cluster and primary query
• Top-ranking page structures for reference
• Internal subject-matter sources

Method

1. List the core concepts a knowledgeable reader expects the page to cover.
2. Add attributes, constraints, and comparisons associated with those concepts.
3. Identify adjacent subjects that belong on a different page and mark them out of scope.
4. Map each in-scope concept to a section of the planned page.
5. Flag concepts requiring subject-matter input or evidence.

Decision rules

• IF a concept requires expertise the team lacks → THEN flag it for a subject-matter interview before drafting
• IF a concept is adjacent but has its own demand → THEN move it out of scope and add it to the cluster backlog

Guardrails

• Never present a concept list as a term-frequency requirement
• Never include concepts the page cannot cover credibly
• Do not copy competitor section structures wholesale

Output

A concept map: in-scope concepts by section, out-of-scope subjects, and items needing expert input.

Definition of done

• Scope boundary stated
• Every concept mapped to a section
• Expert input items flagged

Purpose

Builds the geographic query variations that matter for [MARKET] without generating page templates nobody searches for.

Use when

Before planning location pages or service-area content.

Not for

National content planning.

Inputs

• Service or product list
• Priority locations from SEO_CONTEXT
• Evidence of local demand where available

Method

1. Build the combination grid of services and locations.
2. Add the modifier patterns people actually use in the market language.
3. Filter combinations to those with demand evidence or genuine service coverage.
4. Mark combinations where you can produce genuinely distinct content.
5. Output only the combinations passing both filters.

Decision rules

• IF a combination has demand but no real service coverage → THEN exclude it and note the gap for the business
• IF a combination has coverage but no demand evidence → THEN hold it in a backlog rather than building a page

Guardrails

• Never generate location pages for areas you do not serve
• Never assume demand from population size alone
• Do not fabricate local search volumes

Output

A filtered combination table: service, location, modifier pattern, demand evidence, coverage status.

Definition of done

• Both filters applied
• Excluded combinations listed with reasons
• Market language verified

Purpose

Identifies recurring demand cycles in supplied data and converts them into publishing and refresh dates.

Use when

During annual planning, and before interpreting any performance drop.

Not for

Explaining a one-off change with no historical pattern.

Inputs

• At least 24 months of impression or demand data
• Cluster to query mapping
• Business calendar events

Method

1. Plot demand by month per cluster across all supplied years.
2. Identify patterns repeating in at least two complete years and mark single-year spikes separately.
3. Determine the lead time each cluster needs before its peak.
4. Produce the publish-by and refresh-by date for each seasonal cluster.
5. List clusters with no reliable pattern.

Decision rules

• IF a pattern appears in only one year → THEN treat it as an event, not seasonality
• IF a cluster peaks within eight weeks → THEN set the publish-by date at least one quarter earlier

Guardrails

• Never infer seasonality from fewer than two complete cycles
• Never attribute a decline to seasonality without the historical data to support it
• Do not extrapolate a trend line beyond the supplied data

Output

A seasonal calendar: cluster, peak window, lead time, publish-by date, refresh-by date, and confidence.

Definition of done

• Minimum two cycles verified
• Single-year spikes separated
• Dates assigned per cluster

Purpose

Anticipates the follow-up questions a search or AI system may generate from a primary query, and checks whether your page serves them.

Use when

When optimising for AI answers and multi-step search journeys.

Not for

Traditional keyword volume research.

Inputs

• Primary query and cluster
• Current page content
• Known follow-up questions from the question bank

Method

1. Decompose the primary query into the sub-questions required to answer it fully.
2. Add the natural next questions a reader would ask after receiving the answer.
3. Check which of these the current page answers explicitly and extractably.
4. Identify sub-questions answered elsewhere on the site but not linked from this page.
5. Specify the sections or links needed to close each gap.

Decision rules

• IF a sub-question is answered on another page → THEN recommend a contextual link rather than duplicating the answer
• IF a sub-question has no answer anywhere on the site → THEN route it to the content backlog

Guardrails

• Never assume a fan-out question exists without a linguistic or evidence basis
• Never duplicate answers across pages to cover fan-out
• Do not claim knowledge of any engine's internal query expansion behaviour

Output

A fan-out map: sub-question, answered on this page, answered elsewhere, or missing, with the action per row.

Definition of done

• Every sub-question has a status
• Actions distinguish linking from writing
• No duplicated answers recommended

Purpose

Detects where multiple URLs target the same primary query before the content is written.

Use when

During planning, and before publishing any new page.

Not for

Resolving an existing cannibalisation problem in live data; use the reporting skill for that.

Inputs

• Planned cluster to URL mapping
• Existing page to query mapping
• Site search or crawl export of titles and H1s

Method

1. Match each planned primary query against existing page targets.
2. Flag exact and near-exact target overlaps.
3. Check whether overlapping pages serve different intents or the same one.
4. Recommend one of three resolutions: merge, differentiate, or retarget the new page.
5. Record the decision so the mapping stays authoritative.

Decision rules

• IF an existing page already targets the planned primary query → THEN block publication until the overlap is resolved
• IF two pages target the same query but different intents → THEN retarget one and document the distinction

Guardrails

• Never publish a second page on a query without a documented differentiation
• Never resolve overlap by deleting a ranking page
• Do not assume different URLs mean different targets

Output

An overlap register: planned query, conflicting URL, intent comparison, resolution, and decision owner.

Definition of done

• Every planned query checked against the existing map
• Resolution recorded per conflict
• Mapping updated

Purpose

Defines the entities your site should be associated with — products, categories, people, places, and concepts — and how they are expressed.

Use when

When building topical authority or preparing for AI search visibility.

Not for

Schema markup implementation; that comes after this map exists.

Inputs

• Brand and product definitions from SEO_CONTEXT
• Existing about, product, and author pages
• Category vocabulary used in the market

Method

1. List the entities the business must own, be associated with, or be distinguished from.
2. For each, record the canonical name, accepted variants, and the one-sentence definition.
3. Identify where each entity is currently defined on the site.
4. Flag entities with no canonical definition page.
5. Note inconsistent descriptions across existing pages.

Decision rules

• IF an entity has no definition page → THEN recommend creating one before pursuing related queries
• IF descriptions conflict across pages → THEN designate one source of truth and align the rest

Guardrails

• Never invent relationships between entities that have no connection to the business
• Never publish entity claims that cannot be substantiated
• Do not use different definitions of the same entity across pages

Output

An entity register: entity, canonical name, variants, definition, source-of-truth URL, and inconsistencies.

Definition of done

• Every entity has a canonical definition
• Source-of-truth URL assigned or flagged missing
• Inconsistencies listed

Purpose

Identifies which result features appear for your target clusters and what format is required to be eligible.

Use when

Before writing or restructuring a page for a competitive cluster.

Not for

Guaranteeing feature placement.

Inputs

• Target query list
• Observed SERP features per query
• Current page format for each mapped URL

Method

1. Record which features appear for each query and which competitor holds them.
2. Determine the content format each feature requires.
3. Compare that format against the current page structure.
4. List the specific structural changes required per page.
5. Prioritise by feature prominence and effort.

Decision rules

• IF a feature is held by a competitor with a superior source type → THEN note that format alone will not win it
• IF a feature requires content the page cannot honestly provide → THEN skip it and record why

Guardrails

• Never guarantee that a formatting change will win a feature
• Never fabricate features that were not observed
• Do not restructure a well-performing page purely to chase a feature

Output

A feature opportunity table: query, feature, current holder, required format, gap, and priority.

Definition of done

• Features observed, not assumed
• Structural gaps specified per page
• Priority assigned

Purpose

Estimates whether a cluster is worth pursuing when the answer may be satisfied on the results page or in an AI answer.

Use when

During prioritisation of informational clusters.

Not for

Clusters with clear transactional intent.

Inputs

• Cluster list with intent
• Observed SERP and AI answer behaviour for sample queries
• Business goal for the cluster

Method

1. Classify each cluster by how completely a short answer satisfies the query.
2. Note whether the SERP or AI answers already provide that answer directly.
3. Identify what value remains that only a visit can deliver: tools, depth, data, or purchase.
4. Recommend pursue, pursue for visibility only, or deprioritise.
5. For visibility-only clusters, define how success will be measured without clicks.

Decision rules

• IF the full answer fits in two sentences and is already displayed → THEN recommend visibility-only treatment and measure mentions, not clicks
• IF the query requires a decision, a tool, or a purchase → THEN treat click potential as intact

Guardrails

• Never predict click-through rates without supplied data
• Never abandon a cluster solely because an answer is displayed
• Do not measure visibility-only clusters against click targets

Output

A risk table: cluster, answer completeness, current display behaviour, residual value, recommendation, and metric.

Definition of done

• Every cluster has a recommendation
• Measurement defined for visibility-only clusters
• No CTR assumptions invented

Purpose

Reviews the full target keyword portfolio for coverage balance, drift, and orphaned targets.

Use when

Quarterly.

Not for

Building new clusters.

Inputs

• Full query to URL mapping
• Performance export for [DATE RANGE]
• Topic and stage classification

Method

1. Summarise the portfolio by topic, stage, and intent to reveal concentration.
2. Identify targets with no mapped URL and URLs with no target.
3. Find targets where the ranking URL is not the intended one.
4. Flag targets that have not moved in two consecutive periods.
5. Recommend additions, retirements, and remappings.

Decision rules

• IF the ranking URL differs from the intended target → THEN investigate intent match before forcing the intended URL
• IF a target has been static across two periods → THEN review whether the page or the target is wrong

Guardrails

• Never retire a target that still produces conversions
• Never assume a mismatch is an error without checking intent
• Do not report portfolio health without the topic and stage breakdown

Output

A portfolio audit: concentration summary, unmapped targets, orphaned URLs, mismatches, and a change list.

Definition of done

• Concentration reported by topic and stage
• Every mismatch investigated
• Change list has owners

Purpose

Rebuilds a query set for a new [MARKET] and [LANGUAGE] using local search behaviour rather than translation.

Use when

Before entering a new country or launching a new language.

Not for

Translating existing content.

Inputs

• Source market query set
• Local language sources: competitors, forums, customer conversations
• Local product and regulatory naming rules

Method

1. Identify the underlying job behind each source query.
2. Find how that job is expressed locally, using native sources only.
3. Record terms with no local equivalent and terms with no source equivalent.
4. Verify local product, legal, and category naming constraints.
5. Build the local cluster set independently, then compare with the source set.

Decision rules

• IF a source term has no natural local equivalent → THEN build the local cluster from the local phrasing and drop the source term
• IF local regulation restricts a claim or product name → THEN flag it and stop before content planning

Guardrails

• Never translate keywords literally between markets
• Never assume search behaviour transfers across countries sharing a language
• Do not invent local search volumes

Output

A localised cluster set with source mapping, untranslatable terms, local-only clusters, and naming constraints.

Definition of done

• Local sources used, not translations
• Naming and regulatory constraints checked
• Local-only clusters identified

Purpose

Produces the single ranked backlog that content, technical, and link work all draw from.

Use when

Monthly, after the individual analyses have run.

Not for

Replacing the analyses themselves.

Inputs

• Outputs from gap, decay, difficulty, and portfolio skills
• Business priority weights
• Team capacity for the period

Method

1. Collect every candidate opportunity into one list with its source skill.
2. Score each on impact, confidence, and effort using the fixed weights.
3. Deduplicate opportunities that would be solved by the same action.
4. Cut the list to what capacity allows and mark the rest as backlog.
5. State the assumption that would most change the ranking.

Decision rules

• IF two opportunities are resolved by the same action → THEN merge them and sum the impact
• IF confidence is low and effort is high → THEN move it below all low-effort items regardless of impact

Guardrails

• Never score without recording the evidence source
• Never present the backlog without capacity applied
• Do not silently change weights between periods

Output

A single ranked backlog: opportunity, source, scores, merged items, committed versus backlog, and key assumption.

Definition of done

• All source outputs included
• Duplicates merged
• Capacity line drawn explicitly

Purpose

Updates an existing page by replacing only the sections that no longer serve current demand, while protecting everything that already performs.

Use when

When a page has lost position or clicks but still holds topical relevance.

Not for

Rewriting a page that is fundamentally targeting the wrong intent.

Inputs

• Current page content and URL
• Query coverage for the page across [DATE RANGE]
• Position and click data per query

Method

1. Pull the page's current query coverage and list the queries it serves.
2. Flag sections that answer questions no longer appearing in the data.
3. Identify three queries the page nearly ranks for but does not properly serve.
4. Rewrite only those sections, adding the missing answers directly.
5. Preserve the URL, internal links, and every section ranking in the top three.

Decision rules

• IF a section is ranking in the top three → THEN leave it untouched, including its headings and wording
• IF a query has impressions but no matching section → THEN add a new section rather than editing an existing one

Guardrails

• Never change the URL
• Never remove internal links during a refresh
• Never rewrite a top-performing section to make it read better

Output

A revised page with a change log listing every section touched, the reason, and the target query.

Definition of done

• Top-three sections verified untouched
• Three under-served queries addressed
• URL and internal links preserved

Purpose

Decides which topics get investment this cycle based on demand, fit, and existing authority.

Use when

At the start of a planning cycle.

Not for

Ordering individual articles within a topic.

Inputs

• Topic list with cluster counts
• Existing coverage and performance per topic
• Business priorities from SEO_CONTEXT

Method

1. Place every topic on two axes: business proximity and current authority.
2. Assign each quadrant a standing strategy: build, extend, defend, or ignore.
3. Allocate the cycle's capacity across quadrants before choosing topics.
4. Select topics per quadrant and state what success looks like for each.
5. Record which topics were deliberately not chosen.

Decision rules

• IF a topic is high business proximity and low authority → THEN assign it to build and allocate the largest share
• IF a topic is high authority and low business proximity → THEN assign it to defend with maintenance effort only

Guardrails

• Never allocate all capacity to one quadrant without saying so
• Never claim authority without supporting performance data
• Do not leave declined topics undocumented

Output

A two-axis matrix, per-quadrant capacity allocation, selected topics with success criteria, and a declined list.

Definition of done

• Every topic placed
• Capacity allocated before selection
• Declined topics recorded

Purpose

Converts the prioritised backlog into a dated production schedule constrained by real capacity.

Use when

Monthly or quarterly, after prioritisation.

Not for

Deciding what to write about.

Inputs

• Ranked backlog
• Team capacity by role
• Seasonal dates and business events

Method

1. Estimate production effort per item by role, not in generic hours.
2. Place items against capacity, respecting seasonal publish-by dates first.
3. Sequence dependencies: pillar before supporting pages, research before briefs.
4. Reserve a fixed share of capacity for refreshes and unplanned work.
5. Publish the schedule with named owners and review dates.

Decision rules

• IF capacity is exceeded → THEN move items out rather than compressing review steps
• IF a dependency is unscheduled → THEN schedule the dependency first and delay the dependent item

Guardrails

• Never schedule beyond stated capacity
• Never remove review steps to fit the calendar
• Do not schedule a supporting page before its pillar

Output

A dated calendar with owner, effort, dependency, and a reserved refresh allocation.

Definition of done

• Capacity respected
• Dependencies ordered
• Refresh allocation reserved

Purpose

Specifies a pillar page: its scope, its sections, and its relationship to every supporting page.

Use when

When opening a new topic or consolidating scattered coverage.

Not for

Short tactical articles.

Inputs

• Topic architecture map
• Cluster list owned by the pillar
• Existing pages within the topic

Method

1. Define the pillar's scope boundary and state explicitly what it will not cover.
2. Structure sections so each supporting cluster has a summary and a link target.
3. Decide what the pillar answers in full versus what it delegates.
4. Specify the link contract: which supporting pages link up and which the pillar links down to.
5. Identify existing pages to consolidate into the pillar.

Decision rules

• IF a supporting cluster has its own strong demand → THEN summarise it on the pillar and link out rather than covering it in full
• IF an existing page overlaps the pillar's scope → THEN decide merge or differentiate before the pillar is written

Guardrails

• Never build a pillar that duplicates its supporting pages
• Never leave the scope boundary undefined
• Do not consolidate pages with backlinks without a redirect plan

Output

A pillar specification: scope, section outline, delegation rules, link contract, and consolidation list.

Definition of done

• Scope boundary written
• Every owned cluster represented
• Link contract defined in both directions

Purpose

Defines each supporting page's job so it complements rather than competes with the pillar and its siblings.

Use when

After the pillar specification exists.

Not for

Planning the pillar itself.

Inputs

• Pillar specification
• Cluster assigned to this article
• Sibling article list with their targets

Method

1. State the one question this article answers that no sibling answers.
2. Set the depth boundary: what it covers fully and what it links out for.
3. Define the required links up to the pillar and across to siblings.
4. Specify the reader's next step after finishing.
5. Check the target query against every sibling to confirm no overlap.

Decision rules

• IF the article's question overlaps a sibling → THEN merge them or narrow one before briefing
• IF the article cannot answer its question without covering the pillar's scope → THEN reduce its scope and link up

Guardrails

• Never brief two articles with the same primary query
• Never plan a supporting page without a defined link to its pillar
• Do not duplicate the pillar's core explanation

Output

An article specification: unique question, depth boundary, link plan, next step, and overlap check result.

Definition of done

• Unique question stated
• Overlap check completed against all siblings
• Link plan defined

Purpose

Produces a brief a writer can execute without asking follow-up questions.

Use when

Before any page is written or substantially rewritten.

Not for

Editing an existing draft.

Inputs

• Cluster with primary and secondary queries
• Concept map and question bank entries
• Tone, evidence, and claim rules from SEO_CONTEXT

Method

1. State the reader, their situation, and the decision the page supports.
2. Provide the section outline with the question each section answers.
3. Attach required evidence, sources, and internal links per section.
4. Specify format requirements: tables, lists, definitions, and summary placement.
5. List claims requiring approval and words to avoid.

Decision rules

• IF a section requires evidence the team does not have → THEN mark it blocked and route it to research or a subject-matter interview
• IF a required claim needs approval → THEN mark it and do not let drafting begin on that section

Guardrails

• Never brief a word count without a structural reason
• Never include claims that cannot be substantiated
• Do not omit the internal link plan from the brief

Output

A complete brief: reader, decision, outline with questions, evidence, links, format rules, and approval flags.

Definition of done

• Every section has a question
• Evidence and links attached
• Blocked items flagged before drafting

Purpose

Builds the question set that extracts specific, non-obvious expertise from an internal expert.

Use when

Before writing technical, regulated, or high-expertise content.

Not for

General topic research.

Inputs

• Brief outline with sections
• Expert's role and area of authority
• Concepts flagged as needing expert input

Method

1. Identify the sections where public sources cannot supply a credible answer.
2. Write questions that ask for decisions, trade-offs, and failure cases rather than definitions.
3. Add questions that surface numbers, thresholds, and conditions the expert uses in practice.
4. Include one question per section on what most people get wrong.
5. Order questions from concrete experience to general principle.

Decision rules

• IF a question can be answered by a public source → THEN remove it from the interview and research it separately
• IF an answer would reveal confidential information → THEN reframe the question toward the generalisable principle

Guardrails

• Never ask questions whose answers you intend to write yourself
• Never publish expert claims without attribution and approval
• Do not lead the expert toward a predetermined answer

Output

An ordered interview guide with per-section questions, follow-up prompts, and an approval note.

Definition of done

• No question answerable by public sources
• Every flagged section covered
• Approval step included

Purpose

Decides what proof each claim in a page requires before drafting starts.

Use when

On pages making performance, comparison, or technical claims.

Not for

Opinion or narrative pieces with no factual claims.

Inputs

• Brief outline with intended claims
• Available internal data and studies
• Claim approval rules from SEO_CONTEXT

Method

1. List every claim the page intends to make.
2. Classify each as verifiable internally, verifiable externally, or unsupportable.
3. Assign the specific source required for each verifiable claim.
4. Rewrite or remove unsupportable claims before drafting.
5. Record which claims need legal or executive approval.

Decision rules

• IF a claim is unsupportable → THEN remove it or convert it into a clearly labelled opinion
• IF a claim depends on a third-party statistic → THEN require a primary source, not a secondary citation

Guardrails

• Never cite a statistic without a primary source
• Never publish comparative claims about competitors without documented evidence
• Do not let unsupported claims into the draft to be fixed later

Output

An evidence plan: claim, classification, required source, approval status, and drafting clearance.

Definition of done

• Every claim classified
• Primary sources named
• Unsupportable claims removed before drafting

Purpose

Compares what your content covers against what the cluster's readers actually need answered.

Use when

Before refreshing a page or planning a topic expansion.

Not for

Competitive backlink analysis.

Inputs

• Existing page inventory for the topic
• Question bank and cluster list
• Competitor page structures for reference

Method

1. Map every existing page to the questions it answers.
2. List cluster questions with no page answering them.
3. Identify questions answered thinly: mentioned but not resolved.
4. Separate gaps needing a new page from gaps needing a section.
5. Rank gaps by demand evidence and business proximity.

Decision rules

• IF a gap can be closed with a section on an existing page → THEN prefer that over creating a new page
• IF a gap requires expertise or data you lack → THEN flag it as blocked rather than scheduling it

Guardrails

• Never count a mention as coverage
• Never plan a new page for a gap an existing page could absorb
• Do not rank gaps without demand evidence

Output

A gap register: question, current coverage status, closure method, blocker, and priority.

Definition of done

• Coverage verified against live pages
• Section versus page decision made per gap
• Blockers flagged

Purpose

Ranks which existing pages to refresh first, using performance movement and business value.

Use when

Monthly.

Not for

Deciding how to refresh a specific page.

Inputs

• Performance export across two comparable periods
• Page to business value mapping
• Last update date per page

Method

1. Identify pages with meaningful decline in clicks or impressions between periods.
2. Filter out pages whose decline is explained by seasonality or a known cause.
3. Score remaining pages by business value, decline size, and effort to fix.
4. Group pages sharing the same likely cause so they can be fixed together.
5. Produce the ordered refresh queue with expected effort.

Decision rules

• IF a decline matches a documented seasonal pattern → THEN remove the page from the queue and note why
• IF several pages decline with the same likely cause → THEN treat the cause once rather than refreshing each page

Guardrails

• Never queue a refresh without a decline threshold
• Never compare periods of different lengths
• Do not refresh pages whose decline is caused by a technical issue

Output

An ordered refresh queue with decline evidence, likely cause, grouping, and effort estimate.

Definition of done

• Threshold stated
• Seasonality filtered
• Causes grouped

Purpose

Determines why a specific page is losing performance before any rewriting is authorised.

Use when

After the refresh queue identifies a page but before editing it.

Not for

Pages that never performed in the first place.

Inputs

• Page performance history by query
• Current page content
• SERP or competitor changes if observed

Method

1. Separate query-level loss from page-level loss.
2. Check whether lost queries moved to another URL on your own site.
3. Check whether the page still matches the intent its queries now express.
4. Check technical status: indexability, internal links lost, or rendering changes.
5. Name a single primary cause and the evidence for it.

Decision rules

• IF lost queries now rank with another of your URLs → THEN treat it as cannibalisation, not decay
• IF the page is technically impaired → THEN stop and route it to the technical skills before editing content

Guardrails

• Never rewrite a page before naming the cause of decline
• Never assume freshness is the cause
• Do not attribute decline to an algorithm update without evidence

Output

A diagnosis: primary cause, supporting evidence, ruled-out causes, and the correct next skill.

Definition of done

• Cause named with evidence
• Alternatives explicitly ruled out
• Next skill specified

Purpose

Plans the merge of overlapping pages into one authoritative page without losing equity.

Use when

When several pages compete for the same cluster.

Not for

Pages serving genuinely different intents.

Inputs

• Candidate URL set with performance and backlink data
• Content of each candidate
• Internal link map to each candidate

Method

1. Select the destination URL using performance, backlinks, and URL quality.
2. Map every unique section from the sources to a place in the destination.
3. List content that will be dropped and justify each removal.
4. Specify redirects from every source to the destination.
5. Specify internal link updates so no link points at a redirected URL.

Decision rules

• IF a source page has stronger backlinks but weaker content → THEN keep its URL as the destination and move the content into it
• IF a section exists only on a source page and still earns impressions → THEN carry it into the destination unchanged

Guardrails

• Never delete a source page without a redirect
• Never drop content that currently earns impressions without stating the trade-off
• Do not consolidate pages that serve different intents

Output

A consolidation plan: destination, section mapping, dropped content, redirect list, and internal link updates.

Definition of done

• Destination justified by evidence
• Every source section mapped or justified as dropped
• Redirects and link updates specified

Purpose

Decides what to do with content that no longer earns its place: improve, merge, redirect, or retire.

Use when

Annually, or before a migration.

Not for

Recently published content that has not had time to perform.

Inputs

• Full page inventory with age, performance, and backlinks
• Business value mapping
• Content that must be retained for legal or brand reasons

Method

1. Exclude pages younger than the agreed maturity window and protected pages.
2. Classify remaining pages by performance and strategic value.
3. Assign each low performer one action: improve, merge, redirect, or retire.
4. For retirement, specify the status code and any redirect target.
5. Estimate the volume of pages affected per action.

Decision rules

• IF a page has no traffic but holds backlinks → THEN redirect rather than retire
• IF a page has no traffic and serves a legal or support function → THEN retain and exclude from SEO scoring

Guardrails

• Never retire pages without checking backlinks and internal links
• Never treat page count reduction as the goal
• Do not prune content younger than the maturity window

Output

A pruning plan by action with per-page justification, status codes, and redirect targets.

Definition of done

• Maturity window and protections applied
• Backlink check per retirement
• Actions justified individually

Purpose

Designs the pages that serve buyers who are close to a decision.

Use when

When traffic exists at the top of the funnel but not at the point of decision.

Not for

Awareness content.

Inputs

• ICP and buyer objections from SEO_CONTEXT
• Sales call notes or objection lists
• Existing product and pricing pages

Method

1. List the questions buyers ask in the final evaluation stage, in their words.
2. Determine which of those questions have search demand and which do not.
3. Design one page per decision question, not one per keyword.
4. Specify the proof each page must carry: evidence, comparison, and next step.
5. Define the conversion path and what happens after the click.

Decision rules

• IF a decision question has no search demand → THEN keep the page for sales enablement and exclude it from search targets
• IF a question is about competitors → THEN route it to the comparison page skill instead

Guardrails

• Never make competitive claims without documented evidence
• Never design a decision page without a defined next step
• Do not promise outcomes the product cannot demonstrate

Output

A page set specification: decision question, demand status, required proof, conversion path, and owner.

Definition of done

• Questions sourced from real buyer conversations
• Demand status recorded
• Conversion path defined per page

Purpose

Plans scalable page sets built from product data or functionality rather than hand-written articles.

Use when

When a data set or feature can serve many similar queries.

Not for

One-off editorial pieces.

Inputs

• Available data set or feature inventory
• Query pattern evidence for the page type
• Template and engineering constraints

Method

1. Define the repeating query pattern the page set will serve.
2. Specify what makes each generated page genuinely useful and distinct.
3. Set the minimum data requirement below which a page is not generated.
4. Define the template: sections, data fields, and the editorial layer.
5. Specify indexing rules for pages that fall below the data threshold.

Decision rules

• IF a generated page would not meet the minimum data requirement → THEN do not generate it at all
• IF pages differ only by a single variable substitution → THEN redesign the template before proceeding

Guardrails

• Never generate pages that differ only by a swapped word
• Never publish generated pages without an indexing threshold rule
• Do not scale a template before validating on a sample

Output

A page-set specification: query pattern, template, data thresholds, distinctness rules, and indexing policy.

Definition of done

• Minimum data threshold defined
• Distinctness demonstrated on a sample
• Indexing policy written

Purpose

Specifies a fair, evidence-based comparison page that serves buyers evaluating alternatives.

Use when

When your category has established alternatives buyers search for.

Not for

Attacking a competitor.

Inputs

• Comparison criteria that matter to the ICP
• Verified information about each option
• Legal and claim rules from SEO_CONTEXT

Method

1. Define the criteria buyers actually use, taken from sales conversations.
2. Collect verifiable facts per option and record the source and date for each.
3. Present the comparison in a consistent table with identical criteria per option.
4. State plainly where a competitor is a better fit and for whom.
5. Set the review date after which unverified facts must be rechecked.

Decision rules

• IF a fact cannot be verified from a primary source → THEN omit it rather than estimating
• IF a competitor is genuinely stronger on a criterion → THEN state it and explain who should choose them

Guardrails

• Never publish competitor facts without a source and date
• Never claim superiority on criteria you did not test
• Do not present outdated competitor information as current

Output

A comparison specification: criteria, per-option facts with sources and dates, fit statements, and a review date.

Definition of done

• Every fact sourced and dated
• Criteria identical across options
• Honest fit statements included

Purpose

Specifies a page serving people searching for alternatives to a named tool or approach, including yours.

Use when

When alternatives queries show demand in your category.

Not for

Direct head-to-head comparison; use the comparison skill for that.

Inputs

• List of genuine alternatives
• Selection criteria per use case
• Verified facts per alternative

Method

1. Define the use cases that make each alternative the right choice.
2. Describe each option neutrally with sourced facts and a clear best-fit statement.
3. Position your own option honestly within the same structure and format.
4. Add a selection guide keyed to the reader's constraints.
5. Record the source and date for every claim.

Decision rules

• IF your product is not the best fit for a listed use case → THEN say so and name the option that is
• IF an alternative is no longer maintained or available → THEN remove it and note the change date

Guardrails

• Never list fake alternatives to appear comprehensive
• Never give your own option a different evaluation standard
• Do not omit strong alternatives buyers already know

Output

An alternatives page specification: option list, use-case fit, sourced facts, selection guide, and review date.

Definition of done

• Same standard applied to all options
• Sources and dates recorded
• Selection guide keyed to constraints

Purpose

Turns a navigational category or collection page into a page that can rank and convert.

Use when

On e-commerce, marketplace, or directory sites.

Not for

Individual product or article pages.

Inputs

• Category URL and current content
• Query cluster mapped to the category
• Product or item data available for the category

Method

1. Define what the category page must answer beyond listing items.
2. Specify the placement of supporting copy so it does not push items below the fold.
3. Define the filtering and sorting exposure rules for crawlers.
4. Specify internal links to subcategories and the parent category.
5. Define how empty or thin categories are handled.

Decision rules

• IF a category has too few items to be useful → THEN recommend merging it upward and redirecting
• IF supporting copy would push items below the fold → THEN move it below the item grid

Guardrails

• Never place large text blocks above the item listing
• Never let a category page rank for a query its items cannot satisfy
• Do not leave empty categories indexable

Output

A category page specification: content blocks, placement, filter exposure, link plan, and thin-category rule.

Definition of done

• Query cluster mapped
• Placement rules stated
• Thin-category handling defined

Purpose

Creates the reusable structure for a recurring content type so quality does not depend on the writer.

Use when

When the same page type will be produced repeatedly.

Not for

One-off flagship pieces.

Inputs

• Examples of the page type that performed well
• Reader questions the type must answer
• Format and tone rules from SEO_CONTEXT

Method

1. Identify the sections common to the strongest existing examples.
2. Define the required, optional, and forbidden sections for the type.
3. Specify the answer-first opening and summary requirements.
4. Define the internal link and evidence requirements per section.
5. Write the acceptance checklist a draft must pass.

Decision rules

• IF a section appears in strong examples but not weak ones → THEN make it required
• IF a section adds length without answering a reader question → THEN forbid it

Guardrails

• Never impose a template that prevents answering the query directly
• Never require word counts in place of structural requirements
• Do not template content types that vary fundamentally

Output

A page-type template: section list with status, per-section requirements, and an acceptance checklist.

Definition of done

• Sections classified as required, optional, or forbidden
• Each section tied to a reader question
• Checklist testable

Purpose

Finds the specific point of view that differentiates a page in a crowded topic.

Use when

When the cluster is well covered and the plan risks producing a fifth identical article.

Not for

Pages where a neutral reference format is the correct choice.

Inputs

• Top existing pages for the cluster
• Internal data, experience, or opinions available
• Brand position from SEO_CONTEXT

Method

1. Summarise the argument each existing page makes in one sentence.
2. Identify the assumption they all share.
3. List what your business knows or has done that they cannot claim.
4. Formulate two candidate angles that are defensible with your evidence.
5. Select one and state the evidence it depends on.

Decision rules

• IF an angle requires evidence you do not have → THEN discard it rather than asserting it
• IF every existing page already makes your angle → THEN narrow it to a specific audience or condition

Guardrails

• Never manufacture a contrarian position for its own sake
• Never claim experience the business does not have
• Do not select an angle before checking the required evidence exists

Output

A selected angle with the shared assumption it challenges, supporting evidence, and the discarded alternative.

Definition of done

• Existing arguments summarised
• Angle backed by named evidence
• Alternative recorded

Purpose

Plans which external sources a page will cite and verifies they are primary, current, and appropriate.

Use when

On research-backed, technical, or regulated content.

Not for

Purely product-focused pages.

Inputs

• Claim list from the evidence plan
• Candidate sources with dates
• Source quality rules from SEO_CONTEXT

Method

1. Match each claim to a candidate source and check that the source is primary.
2. Verify the publication date and whether more recent data exists.
3. Confirm the source actually states what the claim asserts.
4. Replace secondary citations with the original source wherever possible.
5. Record the full citation and access date for every retained source.

Decision rules

• IF a source is a secondary report of another study → THEN trace and cite the original study
• IF no primary source supports a claim → THEN remove the claim from the page

Guardrails

• Never cite a source you have not verified says what you claim
• Never fabricate citations, authors, dates, or study names
• Do not cite sources whose methodology contradicts the claim

Output

A citation plan: claim, verified source, publication date, access date, and full reference.

Definition of done

• Every claim has a verified primary source
• Dates recorded
• Unsupported claims removed

Purpose

Documents the editorial rules Claude and the team apply to every page, so standards do not vary by author.

Use when

Once per site, then reviewed quarterly.

Not for

Individual page decisions.

Inputs

• Existing style and brand guidelines
• Claim approval and legal constraints
• Examples of accepted and rejected content

Method

1. Write the rules for structure, tone, evidence, claims, and formatting.
2. State the approval path for each content type and claim class.
3. Define what must never appear: prohibited claims, phrases, and formats.
4. Define the review cadence and the owner for each rule set.
5. Provide accepted and rejected examples for each ambiguous rule.

Decision rules

• IF a rule cannot be tested objectively → THEN rewrite it until it can be, or remove it
• IF two rules conflict → THEN state which takes precedence and why

Guardrails

• Never write rules without examples for ambiguous cases
• Never leave approval ownership unassigned
• Do not include rules the team has no capacity to enforce

Output

A governance document: rules by category, approval paths, prohibitions, examples, owners, and review cadence.

Definition of done

• Every rule testable
• Owners named
• Examples supplied for ambiguous rules

Purpose

Rewrites title tags so they match query intent, differentiate from competing results, and survive truncation.

Use when

On new pages, and on pages with impressions but weak click-through.

Not for

Pages already achieving strong click-through at their position.

Inputs

• Current titles and URLs
• Primary query and observed competing titles
• Brand naming rules from SEO_CONTEXT

Method

1. Confirm the primary query for each page from the mapping, not from the current title.
2. Check whether the current title states the page's specific value within the visible length.
3. Write a replacement placing the distinguishing term before the brand suffix.
4. Compare against the competing titles to ensure it is not interchangeable.
5. Flag any page where the title cannot be improved and say why.

Decision rules

• IF a page has strong click-through for its position → THEN leave the title unchanged
• IF the title is truncated before the distinguishing term → THEN restructure rather than shorten wording arbitrarily

Guardrails

• Never write a title the page content does not deliver
• Never remove a brand suffix without checking brand query performance
• Do not stuff secondary queries into the title

Output

A title change table: URL, current title, proposed title, rationale, and no-change flags.

Definition of done

• Primary query verified per page
• Distinguishing term within visible length
• No-change pages justified

Purpose

Rewrites descriptions to set accurate expectations and improve the odds of a considered click.

Use when

On pages with high impressions and low click-through.

Not for

Pages with very low impressions where the sample is unreliable.

Inputs

• Current descriptions
• Impression and click data per page
• Page content summary

Method

1. Identify pages where impressions are sufficient for the click-through figure to be meaningful.
2. Check whether the description answers what the searcher will get on the page.
3. Rewrite with the specific outcome, format, and scope of the page.
4. Remove promises the page does not fulfil.
5. Note that engines may rewrite descriptions and set expectations accordingly.

Decision rules

• IF impressions are below the reliability threshold → THEN leave the page out of this batch
• IF the description promises content the page lacks → THEN fix the page or reduce the promise

Guardrails

• Never promise content the page does not contain
• Never present click-through improvements as guaranteed
• Do not rewrite descriptions on pages with insufficient impression data

Output

A rewrite table: URL, impressions, current and proposed description, and the change rationale.

Definition of done

• Reliability threshold applied
• Promises verified against page content
• Rationale recorded per change

Purpose

Checks that headings describe the content beneath them and form a logical, extractable outline.

Use when

Before publishing, and on any page being refreshed.

Not for

Visual design or typography decisions.

Inputs

• Page heading outline
• Questions the page is meant to answer
• Template heading rules

Method

1. Extract the heading outline and read it as a standalone summary.
2. Check that each heading names the question or subject of its section.
3. Flag headings that are decorative, vague, or duplicated.
4. Verify hierarchy: one H1, no skipped levels, and correct nesting.
5. Rewrite failing headings using the reader's phrasing.

Decision rules

• IF the outline alone does not convey the page content → THEN rewrite the headings until it does
• IF a heading is a marketing phrase → THEN replace it with the question it answers

Guardrails

• Never use headings that do not describe their section
• Never insert headings solely to include a query
• Do not change headings on sections ranking in the top three

Output

A heading audit: current outline, failures with reasons, and the proposed outline.

Definition of done

• Outline readable as a summary
• Hierarchy validated
• Top-three sections preserved

Purpose

Restructures a page so the direct answer appears before the context, explanation, and background.

Use when

On pages where the answer currently appears after several paragraphs of build-up.

Not for

Narrative or story-led formats where sequence is the point.

Inputs

• Page content
• The primary question the page answers
• Format rules from SEO_CONTEXT

Method

1. Locate where the page currently answers its primary question.
2. Write a direct answer of two to four sentences that stands alone.
3. Place it immediately after the H1 and before any context.
4. Move the removed build-up into a later section if it still adds value.
5. Verify the rest of the page supports rather than repeats the answer.

Decision rules

• IF the page cannot answer its question in four sentences → THEN narrow the page's scope or split it
• IF the opening currently ranks for a featured result → THEN preserve it and improve around it

Guardrails

• Never delay the answer to increase reading time
• Never write an opening answer the body contradicts
• Do not repeat the answer verbatim in later sections

Output

A restructured page with the standalone answer block and a note on relocated content.

Definition of done

• Answer stands alone without the surrounding page
• Placed before context
• No contradiction with the body

Purpose

Formats a specific passage to match the structure a result feature requires for the target query.

Use when

When a target query shows a feature your page is close to earning.

Not for

Queries where no feature appears.

Inputs

• Target query and observed feature format
• Current page section addressing the query
• Competing content currently holding the feature

Method

1. Identify the format the feature uses: paragraph, list, table, or steps.
2. Locate the section that should carry it and check its current structure.
3. Reformat that section to the required structure with a clear preceding heading.
4. Keep the passage self-contained so it makes sense out of context.
5. Note that eligibility does not guarantee selection.

Decision rules

• IF the required format does not suit the content → THEN do not force it; improve clarity instead
• IF the page already holds the feature → THEN make no structural change

Guardrails

• Never restructure content into a format that misrepresents it
• Never promise feature acquisition
• Do not remove depth to fit a snippet length

Output

A reformatted passage with the target query, required format, and a before-and-after comparison.

Definition of done

• Format matches the observed feature
• Passage self-contained
• No content accuracy lost

Purpose

Builds a genuine FAQ section from real questions, placed and formatted so it can be extracted.

Use when

On pages where readers have recurring follow-up questions.

Not for

Adding keyword variations disguised as questions.

Inputs

• Question bank entries relevant to the page
• Existing page content
• Schema rules from SEO_CONTEXT

Method

1. Select questions readers actually ask that the page body does not already answer.
2. Write answers of two to four sentences that are complete on their own.
3. Order questions by frequency and by stage of the reader's decision.
4. Place the block where it does not interrupt the primary answer flow.
5. Confirm answer text is visible on the page before any markup is considered.

Decision rules

• IF a question is answered in the body → THEN link to that section instead of duplicating it
• IF an answer requires more than four sentences → THEN give the short answer and link to the full page

Guardrails

• Never invent questions to increase page length
• Never mark up FAQ content that is not visible on the page
• Do not duplicate body answers inside the FAQ

Output

An FAQ block: questions, standalone answers, placement note, and duplication check results.

Definition of done

• Questions sourced from the question bank
• Answers standalone and visible
• No duplication with the body

Purpose

Verifies that a page states plainly what it is about, who it is for, and which entities it refers to.

Use when

On pages competing in ambiguous or crowded topics, and before AI visibility work.

Not for

Pages with a single unambiguous subject already stated.

Inputs

• Page content
• Entity register from the entity map
• Brand and product naming rules

Method

1. Check whether the page names its subject explicitly in the opening.
2. Verify entities are referred to by their canonical names before any abbreviation.
3. Flag pronouns and vague references standing in for entities.
4. Confirm the audience and scope are stated rather than implied.
5. Align descriptions with the entity register.

Decision rules

• IF an entity is introduced only by an abbreviation → THEN add the canonical name at first mention
• IF the page's subject is only implied → THEN add an explicit statement in the opening

Guardrails

• Never introduce an entity name that conflicts with the register
• Never assume the reader has read another page for context
• Do not rely on the title to define the subject

Output

A clarity report: ambiguous references, missing definitions, and proposed replacement wording.

Definition of done

• Subject stated explicitly
• Canonical names used at first mention
• Audience and scope stated

Purpose

Assesses whether individual passages make sense when lifted out of the page.

Use when

On reference, definition, and how-to content.

Not for

Long-form narrative where continuity is deliberate.

Inputs

• Page content with heading structure
• Target queries per section
• Reader questions per section

Method

1. Split the page into passages at heading and paragraph boundaries.
2. Read each passage in isolation and judge whether it answers something completely.
3. Flag passages depending on prior context: unresolved pronouns, implied subjects, or continuing lists.
4. Rewrite flagged passages to be self-contained without adding repetition.
5. Confirm each passage's first sentence carries its main point.

Decision rules

• IF a passage relies on the previous paragraph to make sense → THEN restate the subject once in its opening sentence
• IF restating context would create heavy repetition → THEN merge the passages instead

Guardrails

• Never repeat the same context in every paragraph
• Never break coherent explanations into fragments for extractability
• Do not rewrite passages that already perform in the top three

Output

A passage-level review: passage, extractability verdict, dependency found, and the rewritten opening.

Definition of done

• Every passage assessed
• Dependencies named specifically
• Repetition avoided

Purpose

Identifies which structured data types a page genuinely qualifies for based on its actual content.

Use when

When planning markup for a template or a new page type.

Not for

Validating markup already deployed.

Inputs

• Page content by template
• Currently deployed schema types
• Content elements available per template

Method

1. Inventory the content elements each template actually contains.
2. Match those elements to schema types whose required properties they satisfy.
3. Exclude types requiring content the template does not have.
4. Specify property-to-content-field mapping for each recommended type.
5. State the expected benefit and the eligibility conditions.

Decision rules

• IF a type requires properties the page lacks → THEN exclude it rather than recommending placeholder values
• IF a page would qualify only after adding content → THEN recommend the content change first, then the markup

Guardrails

• Never recommend markup that does not match the page's actual content
• Never mark up ratings, prices, or reviews that do not genuinely exist
• Do not promise rich result display

Output

A schema plan per template: recommended types, property mapping, exclusions with reasons, and prerequisites.

Definition of done

• Every property mapped to a real content field
• Exclusions justified
• Prerequisites listed

Purpose

Improves the sentences most likely to be quoted so that they are accurate, attributable, and stand alone.

Use when

On pages you want cited by publishers or AI answers.

Not for

Pages with no distinctive claims or data.

Inputs

• Page content
• Verified claims and data from the evidence plan
• Brand fact sheet from SEO_CONTEXT

Method

1. Identify the page's most quotable assertions: definitions, findings, and rules.
2. Rewrite each so it holds meaning without the surrounding paragraph.
3. Attach the source, date, or method that makes the statement verifiable.
4. Place the strongest statement early in the relevant section.
5. Check each statement against the brand fact sheet for consistency.

Decision rules

• IF a statement is quotable but unverifiable → THEN add the evidence or soften the claim
• IF a statement conflicts with the brand fact sheet → THEN align it with the fact sheet before publishing

Guardrails

• Never write a quotable claim you cannot substantiate
• Never manufacture statistics to appear citable
• Do not use absolute language where the evidence is conditional

Output

A list of enhanced statements: original, rewritten, supporting evidence, and placement.

Definition of done

• Each statement stands alone
• Evidence attached
• Fact sheet consistency verified

Purpose

Removes ambiguity, filler, and hedging that make a page harder to read and harder to extract.

Use when

Before publishing any page.

Not for

Legally required language that cannot be simplified.

Inputs

• Draft content
• Audience level from SEO_CONTEXT
• Words to avoid list

Method

1. Flag sentences carrying more than one idea and split them.
2. Remove filler openings and phrases that add no information.
3. Replace vague quantifiers with specific figures where evidence exists.
4. Check that terminology matches the audience's level without over-explaining.
5. Verify no prohibited words remain.

Decision rules

• IF a vague quantifier has no supporting figure → THEN remove the claim rather than inventing a number
• IF a term is unavoidable jargon for the audience → THEN keep it and define it once at first use

Guardrails

• Never simplify to the point of changing meaning
• Never invent figures to replace vague wording
• Do not rewrite legally reviewed language

Output

An edited draft with a change summary by category: split sentences, removed filler, and clarified terms.

Definition of done

• No prohibited words remain
• Every vague quantifier resolved or removed
• Meaning preserved

Purpose

Builds a table that lets a reader make a decision without reading the surrounding prose.

Use when

On comparison, pricing, and options content.

Not for

Content with no comparable dimensions.

Inputs

• Options to compare
• Criteria that matter to the reader
• Verified values per option with sources

Method

1. Select criteria the reader actually decides on, not those easiest to fill.
2. Use identical criteria and units across every option.
3. Enter only verified values and mark unknowns as unknown.
4. Add a one-line summary row stating who each option suits.
5. Add the last-verified date to the table.

Decision rules

• IF a value cannot be verified → THEN mark it unknown rather than estimating
• IF a criterion applies to only one option → THEN remove it or reframe it so it applies to all

Guardrails

• Never fill gaps with assumed values
• Never use different units or measurement bases across columns
• Do not omit criteria where your option performs poorly

Output

A comparison table with identical criteria, verified values, unknowns marked, fit summary, and verification date.

Definition of done

• All values sourced or marked unknown
• Criteria consistent
• Verification date present

Purpose

Converts prose into lists where lists genuinely help, and converts false lists back into prose.

Use when

On instructional and enumerative content.

Not for

Analytical content where reasoning must be connected.

Inputs

• Page content
• Purpose of each section
• Template formatting rules

Method

1. Identify sequences, sets, and criteria currently buried in paragraphs.
2. Convert only those where order or enumeration carries meaning.
3. Give each list item a leading term stating what it is.
4. Find lists whose items are full arguments and restore them to prose.
5. Ensure every list is introduced by a sentence naming what it enumerates.

Decision rules

• IF list items each require several sentences of reasoning → THEN convert them back to subsections with headings
• IF a paragraph contains three or more parallel items → THEN convert it to a list

Guardrails

• Never fragment reasoning into bullets
• Never create lists with a single item
• Do not use lists purely to break up page length

Output

A restructured page with each conversion noted and justified in both directions.

Definition of done

• Every list has an introduction
• Items carry leading terms
• False lists converted back

Purpose

Writes the short summary block that tells a reader, in one place, what the page concludes.

Use when

On long or technical pages.

Not for

Short pages where the summary would repeat the whole content.

Inputs

• Full page content
• Primary question and conclusions
• Format rules for summary blocks

Method

1. Extract the page's conclusions, not its topics.
2. Write three to five statements a reader could act on without reading further.
3. Place the summary after the opening answer, before the detail.
4. Verify every statement is supported later in the page.
5. Check that the summary does not introduce claims not present in the body.

Decision rules

• IF a conclusion is not supported in the body → THEN remove it from the summary or add support to the body
• IF the summary would exceed five statements → THEN the page likely covers more than one subject; flag it

Guardrails

• Never introduce new claims in a summary
• Never summarise topics instead of conclusions
• Do not place the summary above the direct answer

Output

A summary block with statements mapped to their supporting sections.

Definition of done

• Every statement mapped to a section
• Conclusions, not topics
• Placement correct

Purpose

Reviews images, video, and embeds for accessibility, discoverability, and page weight.

Use when

On media-heavy pages and templates.

Not for

Creative direction on visual assets.

Inputs

• Media inventory per page with file names, alt text, and sizes
• Page content for context
• Media format and size standards

Method

1. Check alt text describes the image's informational content, not its file name.
2. Flag decorative images carrying descriptive alt text and vice versa.
3. Verify file naming, dimensions, and format against the standards.
4. Check that media supporting a key claim is captioned and attributed.
5. Identify media that could be replaced by text or a table.

Decision rules

• IF an image carries information not stated in text → THEN require the information in text as well
• IF an image is decorative → THEN use empty alt text rather than a description

Guardrails

• Never describe images in alt text in a way that misrepresents them
• Never use alt text to hold keyword lists
• Do not require alt text on purely decorative elements

Output

A media review table: asset, issue, required change, and accessibility status.

Definition of done

• Every asset classified as informative or decorative
• Alt text checked against content
• Standards compliance recorded

Purpose

Checks that a page gives the reader a defensible next step matched to their stage.

Use when

On pages with traffic but no measurable downstream action.

Not for

Pages deliberately built for visibility only.

Inputs

• Page content and current calls to action
• Stage of the reader from the journey map
• Downstream action data if available

Method

1. Identify the reader's stage and the next step appropriate to it.
2. List the current calls to action and where they appear.
3. Flag mismatches: demo requests on early-stage pages, or no step at all on decision pages.
4. Specify one primary next step per page and where it belongs.
5. Note supporting evidence the reader needs before taking it.

Decision rules

• IF a page targets an early stage → THEN recommend a low-commitment next step rather than a sales action
• IF a page has more than one competing primary action → THEN reduce it to one

Guardrails

• Never place a high-commitment action on an early-stage page as the only option
• Never claim conversion improvements without measurement
• Do not add calls to action that interrupt the primary answer

Output

A next-step audit: page, stage, current actions, mismatches, and the specified primary step.

Definition of done

• Stage identified per page
• One primary step defined
• Mismatches listed

Purpose

Checks whether a page's dated content, examples, and references are still accurate.

Use when

Annually per page, or before a refresh.

Not for

Evergreen content with no dated references.

Inputs

• Page content
• Publication and last-update dates
• Referenced products, versions, prices, and statistics

Method

1. List every dated element: years, versions, prices, statistics, and screenshots.
2. Verify each against a current source.
3. Flag elements that are outdated, unverifiable, or now misleading.
4. Distinguish superficial date updates from genuine content changes required.
5. Specify the update needed per element.

Decision rules

• IF only the displayed date is stale but content is accurate → THEN do not change the date without a real content update
• IF a referenced product or version no longer exists → THEN update the reference and note the change

Guardrails

• Never update a last-modified date without a substantive change
• Never leave outdated statistics with new dates attached
• Do not remove historical context that is deliberately dated

Output

A freshness report: element, current state, verified state, and required update.

Definition of done

• Every dated element verified
• Superficial updates rejected
• Required changes specified

Purpose

Writes the short, precise definition of a term that a page should own.

Use when

On pages targeting definitional queries or introducing a category term.

Not for

Pages where the term is already defined authoritatively elsewhere on the site.

Inputs

• Term and its cluster
• Entity register definition
• Existing definitions in the market for comparison

Method

1. Write a one-sentence definition covering the term's category and its distinguishing property.
2. Add two or three sentences on how it works and when it applies.
3. Note explicitly what the term is not, where confusion exists.
4. Check consistency with the entity register and other site pages.
5. Place the block directly under the relevant heading.

Decision rules

• IF the site already defines the term elsewhere → THEN reuse the canonical definition and link to it
• IF market definitions conflict → THEN state your definition and acknowledge the alternative

Guardrails

• Never publish a definition that contradicts the entity register
• Never define a term differently across pages
• Do not pad definitions with marketing language

Output

A definition block with the one-sentence definition, elaboration, boundary statement, and consistency check.

Definition of done

• Consistent with the entity register
• Boundary stated
• Placement specified

Purpose

Checks that proof sits next to the claim it supports rather than at the bottom of the page.

Use when

On pages making performance, comparison, or technical claims.

Not for

Pages with no factual claims.

Inputs

• Page content
• Evidence plan with claim-to-source mapping
• Available data, examples, and citations

Method

1. Locate every claim and the evidence currently supporting it.
2. Flag claims whose evidence is distant, missing, or generic.
3. Move or add evidence adjacent to each claim.
4. Ensure each citation names the source and date inline.
5. Remove claims that remain unsupported after the pass.

Decision rules

• IF evidence sits in a separate section → THEN move the specific proof next to the claim and keep the detail below
• IF a claim has no evidence available → THEN remove the claim

Guardrails

• Never leave a factual claim without adjacent support
• Never cite a source without naming it inline
• Do not group all citations at the end as the only support

Output

A placement report: claim, current evidence location, action taken, and removed claims.

Definition of done

• Every claim mapped to adjacent evidence
• Sources named inline
• Unsupported claims removed

Purpose

Verifies that the first screen confirms to the visitor that the page answers their query.

Use when

On pages with impressions and high early exit behaviour.

Not for

Pages where the format requires a long introduction by design.

Inputs

• Page content and layout order
• Primary query and intent
• Behavioural data if available

Method

1. List what appears before any scrolling: heading, first paragraph, and visual elements.
2. Check whether the query's subject is named there in the reader's own words.
3. Flag interruptions: large media, notices, or promotional blocks pushing the answer down.
4. Specify the minimum content required in the first screen.
5. Recommend the removal or relocation of interruptions.

Decision rules

• IF the first screen does not name the query subject → THEN rewrite the opening to state it plainly
• IF a promotional block precedes the answer → THEN move it below the first answer section

Guardrails

• Never fill the first screen with brand messaging instead of the answer
• Never claim behavioural improvements without measurement
• Do not remove legally required notices

Output

A first-screen audit: current elements, intent match verdict, interruptions, and required changes.

Definition of done

• Query subject present in the first screen
• Interruptions listed
• Required changes specified

Purpose

Adds navigation within long pages so readers and crawlers can reach specific sections.

Use when

On pages longer than roughly 1,500 words with multiple distinct sections.

Not for

Short pages or single-answer pages.

Inputs

• Page heading outline
• Section anchor availability
• Template constraints

Method

1. Build the contents list from the H2 outline, using the headings verbatim.
2. Assign stable anchor identifiers that will not change on edit.
3. Place the contents after the opening answer, not before it.
4. Verify each anchor resolves to the correct section.
5. Exclude sections that are not standalone destinations.

Decision rules

• IF a heading is unclear as a navigation label → THEN fix the heading rather than writing a different label
• IF the page has fewer than four sections → THEN omit the contents block

Guardrails

• Never use labels that differ from the actual headings
• Never place the contents above the direct answer
• Do not create anchors that change with content edits

Output

A contents block with anchor identifiers, placement note, and a resolution check per link.

Definition of done

• Labels match headings
• Anchors stable and resolving
• Placement after the answer

Purpose

Determines whether a page is trying to serve two intents and specifies how to split it.

Use when

When a page ranks inconsistently across its target queries or covers unrelated sections.

Not for

Pages with one clear intent and a long body.

Inputs

• Page content and outline
• Query performance by section topic
• Cluster mapping for the page

Method

1. Group the page's target queries by intent and required page type.
2. Check whether one page format can serve all groups honestly.
3. If not, define the split: which sections move, which stay, and what each new page owns.
4. Specify URL treatment, redirects, and internal link updates for the split.
5. Define what each resulting page must gain to stand alone.

Decision rules

• IF all queries share one intent → THEN do not split; deepen the page instead
• IF a section serves a distinct intent with its own demand → THEN move it to a new page and link between them

Guardrails

• Never split a page ranking well across all its queries
• Never create a new page that cannot stand alone
• Do not split without a redirect and internal link plan

Output

A split decision: verdict, section allocation, new page specifications, URL plan, and link updates.

Definition of done

• Intent grouping evidenced
• Standalone viability confirmed
• URL and link plan specified

Purpose

Treats internal links as votes rather than decoration: maps pages to query clusters and proposes links only where they are justified.

Use when

Monthly, and after publishing any batch of new pages.

Not for

Designing site navigation menus.

Inputs

• Crawl export with internal links, depth, and anchors
• Page to query cluster mapping
• Body content of candidate source pages

Method

1. Map every page to its target query cluster.
2. Find orphan pages and pages more than three clicks deep.
3. Propose links only where the anchor phrase already appears naturally in the source body copy.
4. Cap outbound internal links per page at the agreed threshold.
5. Never link two pages competing for the same primary query unless a documented strategic reason exists.

Decision rules

• IF a candidate anchor does not appear naturally in the source copy → THEN reject the link rather than inserting forced wording
• IF two pages target the same primary query → THEN send the link to the cannibalisation resolution path instead

Guardrails

• Never link pages competing for the same primary query
• Never exceed the outbound link cap to place more recommendations
• Never insert anchors that do not fit the sentence they sit in

Output

A link plan: source URL, target URL, exact anchor, sentence location, and justification per link.

Definition of done

• Every page mapped to a cluster
• Orphans and deep pages listed
• Each link has a natural anchor and stays within the cap

Purpose

Finds pages with no internal links pointing to them and decides whether to link, merge, or retire each one.

Use when

Monthly, and after migrations or bulk publishing.

Not for

Pages intentionally excluded from internal linking, such as landing pages for paid campaigns.

Inputs

• Crawl export with inbound internal link counts
• Sitemap and index coverage lists
• Performance data per orphan

Method

1. Identify indexable URLs with zero inbound internal links.
2. Exclude intentionally unlinked pages using the protected list.
3. Assess each remaining orphan for demand, performance, and strategic value.
4. Assign one action per orphan: link from a relevant hub, merge, or retire.
5. For pages to be linked, identify the specific source pages and anchors.

Decision rules

• IF an orphan has impressions but no internal links → THEN prioritise linking it from the closest relevant hub
• IF an orphan has no demand and no strategic value → THEN route it to the pruning skill

Guardrails

• Never link orphans from unrelated pages to fix the count
• Never retire an orphan without checking backlinks
• Do not treat campaign landing pages as errors

Output

An orphan register: URL, exclusion status, evidence, assigned action, and proposed link sources.

Definition of done

• Protected pages excluded
• Every orphan has an action
• Link sources named per linked page

Purpose

Brings valuable pages closer to the site's main entry points through targeted structural links.

Use when

When priority pages sit deeper than three clicks.

Not for

Reducing depth of low-value archive pages.

Inputs

• Crawl export with click depth
• Page value tiers
• Existing hub and navigation structure

Method

1. List priority pages beyond depth three and their current shortest path.
2. Identify the single link that would most reduce depth for each group.
3. Prefer changes to shared parents over per-page links.
4. Model the new depth distribution after the proposed changes.
5. Check that the proposed links pass the natural anchor test.

Decision rules

• IF many deep pages share one parent → THEN improve the parent's exposure once
• IF depth cannot be reduced without adding navigation clutter → THEN leave it and record the trade-off

Guardrails

• Never add navigation entries solely to reduce a depth metric
• Never bypass topical grouping to shorten a path
• Do not report modelled depth as measured depth

Output

A depth plan: page group, current depth, proposed change, modelled new depth, and anchor check result.

Definition of done

• Value tiers applied
• Shared-parent fixes preferred
• Modelled results labelled as modelled

Purpose

Establishes the link contract between a pillar page and its supporting pages in both directions.

Use when

After publishing a topic cluster, and when a cluster underperforms as a whole.

Not for

Unrelated pages that share no topic.

Inputs

• Topic architecture map
• Current internal links within the cluster
• Body content of pillar and spokes

Method

1. Verify the pillar links to every supporting page with a descriptive anchor.
2. Verify every supporting page links back to the pillar within body copy.
3. Identify spoke-to-spoke links that are justified by the reader's next question.
4. Remove or flag links between spokes that exist only for link volume.
5. Document the contract so new spokes are linked at publication.

Decision rules

• IF a supporting page has no body link to the pillar → THEN add one in the section where the pillar's subject is referenced
• IF two spokes cover sequential steps → THEN link them in reading order only

Guardrails

• Never link every spoke to every other spoke
• Never place pillar links only in footers or sidebars
• Do not add a spoke to a cluster without applying the contract

Output

A cluster link map with missing links, surplus links, and the documented contract for new pages.

Definition of done

• Both directions verified
• Surplus spoke links removed
• Contract documented

Purpose

Finds existing sentences across the site where a target page could be linked naturally.

Use when

When a specific page needs more internal support.

Not for

Bulk link insertion across unrelated pages.

Inputs

• Target URL and its primary query
• Full-text crawl export of candidate source pages
• Existing links to the target

Method

1. Search body content for phrases matching the target's subject and query cluster.
2. Exclude pages already linking to the target and pages competing with it.
3. Rank candidate sources by topical proximity and page authority signals available.
4. Extract the exact sentence and the anchor phrase within it.
5. Cap the number of new links to the agreed threshold per target.

Decision rules

• IF a candidate sentence would require rewording to fit the anchor → THEN reject it
• IF a candidate source targets the same primary query → THEN exclude it

Guardrails

• Never insert links into sentences that must be rewritten to accommodate them
• Never add more links than the per-target cap
• Do not link from pages competing for the same query

Output

An opportunity list: source URL, exact sentence, anchor phrase, proximity score, and approval status.

Definition of done

• Sentences quoted verbatim
• Competing pages excluded
• Cap respected

Purpose

Reviews the anchors pointing to each page for descriptiveness, variety, and accuracy.

Use when

Quarterly, and after bulk additions.

Not for

External backlink anchor analysis.

Inputs

• Internal link export with anchor text per link
• Page to query cluster mapping
• Anchor rules from SEO_CONTEXT

Method

1. Aggregate anchors by destination page.
2. Flag non-descriptive anchors and anchors that misdescribe the destination.
3. Check whether anchor variety reflects the destination's cluster or a single repeated phrase.
4. Identify anchors matching a different page's target query.
5. Propose replacements that fit the existing sentence.

Decision rules

• IF an anchor describes a different page's target → THEN change the anchor or the destination
• IF all anchors to a page are identical → THEN diversify only where the sentence supports it

Guardrails

• Never rewrite surrounding copy purely to change an anchor
• Never use anchors that misdescribe the destination
• Do not manufacture variety that reads unnaturally

Output

An anchor audit by destination: anchor inventory, issues, and proposed replacements with sentence context.

Definition of done

• Every destination reviewed
• Misdescribing anchors flagged
• Replacements fit existing sentences

Purpose

Decides which of two competing pages should receive internal links, and enforces it.

Use when

When cannibalisation is detected and both pages must remain live.

Not for

Pages that are being merged.

Inputs

• The competing URLs and their query targets
• Performance data per URL
• Current internal links to each

Method

1. Confirm the two pages genuinely target the same primary query.
2. Select the page to support using performance, intent match, and strategic role.
3. Redirect internal links from the secondary page's anchors to the primary where the sentence allows.
4. Retarget the secondary page to a distinct query or reduce its scope.
5. Record the decision so future linking follows it.

Decision rules

• IF the secondary page has stronger backlinks → THEN consider making it primary rather than splitting support
• IF neither page can be retargeted → THEN escalate to consolidation

Guardrails

• Never split internal support evenly between competing pages
• Never change a target without updating the query mapping
• Do not remove links without checking the sentence still reads correctly

Output

A referee decision: primary page, supporting evidence, link reassignments, and the secondary page's new target.

Definition of done

• Primary page justified
• Link reassignments listed
• Mapping updated

Purpose

Finds internal links pointing to broken or redirected URLs and specifies the correct destination.

Use when

Weekly on active sites.

Not for

External outbound link checking.

Inputs

• Crawl export with link source, target, and status
• Redirect map
• Live URL inventory

Method

1. List internal links resolving to 4xx, 5xx, or redirect responses.
2. Group them by target URL to fix the cause once.
3. For redirected targets, specify the final destination as the new link target.
4. For broken targets, identify the closest live equivalent or remove the link.
5. Order fixes by number of affected source pages.

Decision rules

• IF a link points to a redirect → THEN update it to the final destination rather than leaving the hop
• IF no relevant live equivalent exists → THEN remove the link and adjust the sentence

Guardrails

• Never leave a sentence broken after removing a link
• Never link to a URL that redirects when the destination is known
• Do not fix symptoms while the source template keeps generating the link

Output

A fix list grouped by target: current target, status, new destination, affected sources, and template cause.

Definition of done

• All links grouped by target
• Template causes identified
• Sentence integrity preserved

Purpose

Evaluates the main navigation for the balance between user needs and link equity distribution.

Use when

During redesigns, or when navigation has grown organically.

Not for

Body content linking.

Inputs

• Current navigation structure
• Page value tiers and performance
• Crawl depth data

Method

1. List every navigation entry and the pages it exposes.
2. Identify high-value pages absent from navigation and low-value pages occupying slots.
3. Assess whether labels match how visitors describe the destinations.
4. Measure the depth effect of each navigation change considered.
5. Recommend additions and removals with the reasoning for each.

Decision rules

• IF a high-value section is absent from navigation → THEN propose an entry and identify what it replaces
• IF navigation exceeds what visitors can scan → THEN recommend grouping rather than adding entries

Guardrails

• Never add navigation entries without removing or grouping others
• Never use labels that differ from the destination page's subject
• Do not treat navigation as the only way to reduce depth

Output

A navigation recommendation: current entries, proposed changes, depth effect, and label revisions.

Definition of done

• Every proposed addition has a trade-off
• Labels validated against destinations
• Depth effect modelled

Purpose

Specifies breadcrumb trails that reflect the true hierarchy and support navigation and markup.

Use when

On sites with more than two levels of hierarchy.

Not for

Flat sites with a single level.

Inputs

• URL structure and hierarchy map
• Current breadcrumb implementation
• Category taxonomy

Method

1. Define the canonical hierarchy path for each template.
2. Check that current breadcrumbs match that path and the URL structure.
3. Resolve pages belonging to multiple parents by designating a primary path.
4. Specify the markup and link behaviour for each level.
5. Flag hierarchy conflicts between breadcrumbs, navigation, and URLs.

Decision rules

• IF a page has multiple valid parents → THEN designate one primary path and keep the others as contextual links
• IF breadcrumbs contradict the URL structure → THEN flag the conflict and choose one source of truth

Guardrails

• Never show a breadcrumb path that does not exist as a navigable hierarchy
• Never mark up breadcrumbs that differ from the visible trail
• Do not include the current page as a link

Output

A breadcrumb specification per template with primary paths, markup rules, and conflict list.

Definition of done

• Primary path defined per template
• Conflicts documented
• Markup matches visible trail

Purpose

Reviews URL structure for consistency, readability, and alignment with the content hierarchy.

Use when

Before a migration or when launching a new section.

Not for

Changing URLs of established, performing pages.

Inputs

• Full URL inventory by template
• Content hierarchy map
• Protected URLs from SEO_CONTEXT

Method

1. Document the current URL patterns by template and their inconsistencies.
2. Compare patterns against the content hierarchy and flag mismatches.
3. Define the target pattern for each template.
4. Separate new-page rules from existing-page changes.
5. Recommend changes only where the benefit exceeds the migration risk.

Decision rules

• IF an existing URL performs well but breaks the pattern → THEN leave it and apply the pattern to new pages only
• IF a URL pattern conflicts with a protected URL rule → THEN stop and request a decision

Guardrails

• Never change URLs of performing pages without a documented business reason
• Never recommend URL changes without a redirect plan
• Do not touch protected URLs listed in SEO_CONTEXT

Output

A URL standard: target pattern per template, new-page rules, change candidates, and risk notes.

Definition of done

• Protected URLs respected
• New-page rules separated from changes
• Risk stated per change

Purpose

Designs the category and tag system so it serves both navigation and search demand.

Use when

When categories have grown organically or overlap.

Not for

Individual page classification.

Inputs

• Current category and tag inventory with page counts
• Query cluster list
• Traffic per category page

Method

1. List every category and tag with its page count and performance.
2. Identify overlapping, empty, and single-page classifications.
3. Map categories to query clusters and flag those with no demand.
4. Define the target taxonomy with rules for creating new terms.
5. Specify merges, retirements, and redirects.

Decision rules

• IF a tag has fewer than the minimum page count → THEN merge it into a broader term
• IF two categories map to the same cluster → THEN merge them and redirect one

Guardrails

• Never allow free-form tag creation without rules
• Never retire a taxonomy term with traffic without a redirect
• Do not create categories with no supporting content

Output

A taxonomy specification: target terms, creation rules, merge and retirement list, and redirect map.

Definition of done

• Every current term classified
• Creation rules written
• Redirects specified

Purpose

Decides which filter links are exposed as crawlable anchors in the interface.

Use when

On filtered listing interfaces.

Not for

Robots directives; the technical facet skill covers those.

Inputs

• Facet governance tiers
• Current link markup for filters
• Template implementation details

Method

1. List every filter control and how it is currently rendered as a link.
2. Compare exposure against the governance tiers.
3. Specify which controls should be crawlable anchors and which should not.
4. Define the implementation mechanism for non-crawlable controls.
5. Verify indexable facet pages remain reachable by at least one crawlable path.

Decision rules

• IF a filter is tier-blocked but rendered as a crawlable link → THEN specify a non-anchor control
• IF an indexable facet page has no crawlable link path → THEN add one from the category page

Guardrails

• Never leave an indexable facet page without a crawlable entry point
• Never expose blocked facets as anchors and rely on directives alone
• Do not change link exposure without checking current rankings

Output

An exposure specification per filter: current rendering, required rendering, mechanism, and reachability check.

Definition of done

• Every filter mapped to a tier
• Reachability confirmed for indexable facets
• Mechanism specified

Purpose

Models how internal link equity concentrates and where it is wasted.

Use when

On large sites, before restructuring.

Not for

Small sites where the link graph is trivially small.

Inputs

• Complete internal link graph export
• Page value tiers
• Current entry point distribution

Method

1. Build the link graph and compute relative internal link scores.
2. Compare score distribution against page value tiers.
3. Identify high-score pages of low value and low-score pages of high value.
4. Trace where equity is absorbed: utility pages, archives, and duplicated navigation targets.
5. Model the effect of two or three specific structural changes.

Decision rules

• IF a low-value page receives disproportionate internal links → THEN identify the template generating them
• IF a high-value page has few inbound links → THEN route it to the contextual link finder

Guardrails

• Never present modelled internal scores as external authority metrics
• Never restructure based on the model alone without checking user needs
• Do not include nofollowed or non-crawlable links in the graph

Output

A flow model: distribution by tier, mismatches, absorption points, and modelled effects of proposed changes.

Definition of done

• Graph completeness verified
• Mismatches named
• Model clearly labelled as a model

Purpose

Determines whether archive, tag, author, and date pages earn their place in the index and the link graph.

Use when

On publisher and blog-heavy sites.

Not for

Primary category pages with demand.

Inputs

• Inventory of archive-type URLs with performance
• Internal link counts to and from them
• Taxonomy specification

Method

1. Classify archive URLs by type and count how many the site generates.
2. Check performance and demand evidence for each type.
3. Assess whether each type provides a discovery path not available elsewhere.
4. Assign an action per type: keep and improve, noindex but keep crawlable, or remove.
5. Specify how removal affects discovery of the items they list.

Decision rules

• IF an archive type provides the only discovery path for its items → THEN keep it crawlable regardless of its own performance
• IF an archive type has no demand and no unique discovery role → THEN recommend removal

Guardrails

• Never remove an archive type without checking item discovery
• Never noindex pages that are the sole crawl path to content
• Do not treat archive volume as automatically harmful

Output

An archive decision table: type, volume, performance, discovery role, action, and discovery impact.

Definition of done

• Discovery role assessed per type
• Actions specified
• Impact on item discovery documented

Purpose

Detects when pages lose internal links over time due to pagination, template changes, or content removal.

Use when

Monthly, comparing consecutive crawls.

Not for

Analysing external link loss.

Inputs

• Current and previous internal link exports
• Page value tiers
• Template change log if available

Method

1. Compare inbound internal link counts per URL between periods.
2. Flag pages losing links beyond the agreed threshold.
3. Identify the mechanism: content removal, pagination drift, or template change.
4. Prioritise losses affecting high-value pages.
5. Recommend replacement links where the loss is not intentional.

Decision rules

• IF a page loses links because it moved off a paginated listing → THEN recommend a durable link from a hub
• IF link loss follows intentional content removal → THEN record it and take no action

Guardrails

• Never compare crawls with different settings
• Never restore links that were intentionally removed
• Do not treat all link loss as harmful

Output

A decay report: URL, previous and current link counts, mechanism, value tier, and recommended action.

Definition of done

• Crawl settings matched
• Mechanism identified per loss
• Intentional removals excluded

Purpose

Documents which page owns which, so link direction and hierarchy decisions are consistent.

Use when

When building or restructuring a section.

Not for

Flat content sets with no hierarchy.

Inputs

• Page inventory with topic assignment
• Current link directions
• URL structure

Method

1. Assign every page a parent and record pages with none.
2. Detect cycles and pages claimed by multiple parents.
3. Verify the link direction matches the declared relationship.
4. Align the hierarchy with URL structure and breadcrumbs, or document the divergence.
5. Publish the map as the reference for future linking decisions.

Decision rules

• IF a page has two claimed parents → THEN designate one and record the secondary relationship as contextual
• IF link direction contradicts the hierarchy → THEN correct the links, not the hierarchy, unless the hierarchy is wrong

Guardrails

• Never leave hierarchy undocumented on sites with more than two levels
• Never allow cycles in the parent map
• Do not silently diverge from the URL structure

Output

A hierarchy map: page, parent, children, conflicts resolved, and divergences documented.

Definition of done

• Every page has a parent or is recorded as top level
• Cycles resolved
• Divergences documented

Purpose

Ensures every newly published page receives its links on the day it goes live.

Use when

At publication of any new page.

Not for

Pages already live for more than one crawl cycle.

Inputs

• New page URL and cluster
• Pillar and sibling pages in the cluster
• Contextual link opportunities identified

Method

1. Confirm the pillar links to the new page with a descriptive anchor.
2. Confirm the new page links back to the pillar in body copy.
3. Add the identified contextual links from existing pages.
4. Verify sitemap inclusion and internal reachability within three clicks.
5. Record the links added so future audits can trace them.

Decision rules

• IF no natural anchor exists on any source page → THEN flag the page as unsupported and review its cluster fit
• IF the page is not reachable within three clicks → THEN add a hub link before considering the launch complete

Guardrails

• Never publish a page without at least one contextual internal link
• Never insert forced anchors to satisfy the checklist
• Do not rely on the sitemap as the only discovery path

Output

A launch record: links added with anchors, reachability confirmation, and any unsupported flags.

Definition of done

• Pillar links in both directions
• Reachable within three clicks
• Links recorded

Purpose

Reviews site-wide template links for volume, relevance, and their effect on equity distribution.

Use when

During redesigns or when site-wide link counts are high.

Not for

Contextual body links.

Inputs

• Template link inventory for footer, sidebar, and headers
• Page value tiers
• Total outbound link counts per page

Method

1. Count site-wide links and calculate their share of total outbound links per page.
2. Assess each link's purpose: navigation, compliance, or equity distribution.
3. Flag links serving none of those purposes.
4. Recommend removals and, where useful, contextual replacements.
5. Verify compliance links remain intact.

Decision rules

• IF a site-wide link exists purely for equity distribution → THEN replace it with contextual links from relevant pages
• IF a site-wide link is legally required → THEN retain it regardless of volume considerations

Guardrails

• Never remove legally required links
• Never add site-wide links to boost specific pages
• Do not evaluate site-wide links without measuring their share of the total

Output

A site-wide link audit: link, purpose, share of outbound links, recommendation, and compliance status.

Definition of done

• Purpose assigned per link
• Share measured
• Compliance links protected

Purpose

Plans the small number of links that connect distinct topic clusters where the reader's journey requires it.

Use when

When clusters are strong individually but the site reads as disconnected silos.

Not for

Linking within a single cluster.

Inputs

• Topic architecture map
• Buyer journey stage mapping
• Existing cross-cluster links

Method

1. Identify the reader transitions that genuinely occur between clusters.
2. Select the single best page in each cluster to serve as the bridge point.
3. Define the anchor and the sentence context for each bridge link.
4. Cap the number of bridges per cluster pair.
5. Verify bridges do not connect pages competing for the same query.

Decision rules

• IF a transition is speculative rather than observed → THEN do not build the bridge
• IF two clusters have more than two justified bridges → THEN review whether they are actually one cluster

Guardrails

• Never create bridge links between unrelated topics
• Never exceed the bridge cap per cluster pair
• Do not bridge from pages that compete for the same query

Output

A bridge plan: cluster pair, transition rationale, source and target pages, anchor, and sentence context.

Definition of done

• Transitions evidenced
• Cap respected
• Competition check performed

Purpose

Specifies the logic behind automated related-content modules so they support the link strategy.

Use when

When related-content modules are automated and their output is unpredictable.

Not for

Manually curated in-body links.

Inputs

• Current module logic and sample outputs
• Cluster mapping
• Link cap rules

Method

1. Document the current selection logic and sample its output across templates.
2. Identify selections that are irrelevant or that link competing pages.
3. Define the required selection rules: cluster proximity, exclusions, and ordering.
4. Specify the module's link count and its contribution to the outbound cap.
5. Define fallback behaviour when no qualifying pages exist.

Decision rules

• IF the module surfaces a competing page → THEN add an exclusion rule for same-primary-query pages
• IF no qualifying related pages exist → THEN hide the module rather than filling it with unrelated links

Guardrails

• Never let automated modules link pages competing for the same query
• Never fill modules with unrelated content to maintain a fixed count
• Do not exclude module links from the outbound link cap

Output

A module specification: selection rules, exclusions, ordering, link count, and fallback behaviour.

Definition of done

• Rules exclude competing pages
• Fallback defined
• Cap contribution accounted for

Purpose

Checks what actually changed after a batch of internal link work, and records the result.

Use when

Four to eight weeks after implementing a link plan.

Not for

Immediately after implementation, before any data exists.

Inputs

• The implemented link plan with dates
• Performance data before and after
• Crawl data showing depth and link count changes

Method

1. Confirm which planned links were actually implemented.
2. Compare depth, inbound link counts, and crawl frequency for affected pages.
3. Compare performance across matched periods for affected and unaffected pages.
4. Separate changes plausibly linked to the work from site-wide movement.
5. Record the outcome and what it implies for the next link cycle.

Decision rules

• IF affected and unaffected pages moved together → THEN attribute the change to site-wide factors, not the link work
• IF implementation was partial → THEN report on implemented links only

Guardrails

• Never claim causation without a comparison group
• Never report results before the measurement window closes
• Do not include unimplemented links in the results

Output

An impact review: implementation status, structural changes, matched performance comparison, and conclusion.

Definition of done

• Implementation verified
• Comparison group used
• Conclusion states confidence level

Purpose

Identifies the types of sites linking to [COMPETITORS] but not to [DOMAIN], grouped by the reason they link.

Use when

Quarterly, and before planning an outreach cycle.

Not for

Judging the value of an individual link.

Inputs

• Backlink exports for own domain and competitors
• Linking page context where available
• Relevance rules from SEO_CONTEXT

Method

1. Normalise the link sets to referring domains and remove duplicates.
2. Identify domains linking to competitors only.
3. Group them by the reason the link exists: coverage, resource listing, partnership, or data citation.
4. Filter out domains irrelevant to your market or audience.
5. Rank remaining groups by how repeatable the acquisition reason is.

Decision rules

• IF a linking reason cannot be replicated honestly → THEN exclude the group from the plan
• IF several competitors share the same linking group → THEN prioritise it as a category-level pattern

Guardrails

• Never invent link metrics or domain scores
• Never target links that require payment or exchange schemes
• Do not treat volume of missing links as the objective

Output

A gap report: linking groups, acquisition reason, replicability, relevance filter results, and priority.

Definition of done

• Links grouped by reason, not listed raw
• Relevance filter applied
• Non-replicable groups excluded

Purpose

Applies a consistent qualification standard so outreach targets a defensible list.

Use when

Before any outreach begins.

Not for

Evaluating links you already have.

Inputs

• Raw prospect list with URLs
• Qualification criteria from SEO_CONTEXT
• Evidence of each site's audience and activity

Method

1. Verify each site is active, has genuine readership signals, and is topically relevant.
2. Check whether the site publishes the kind of content your asset fits.
3. Disqualify sites showing paid-link patterns or unrelated topic mixing.
4. Record the specific reason each prospect qualifies or fails.
5. Assign an outreach angle to each qualified prospect.

Decision rules

• IF a site publishes sponsored links without disclosure patterns you can verify → THEN disqualify it
• IF a site is relevant but has no format your asset fits → THEN keep it and note the required asset

Guardrails

• Never qualify a prospect on domain metrics alone
• Never include sites that sell links
• Do not proceed to outreach without a per-prospect angle

Output

A qualified prospect list: site, relevance evidence, qualification decision, reason, and outreach angle.

Definition of done

• Every prospect has a documented reason
• Paid-link patterns excluded
• Angle assigned per qualified prospect

Purpose

Finds published mentions of [BRAND] that do not link back, and prepares the request.

Use when

Monthly.

Not for

Creating new coverage; this works with existing mentions only.

Inputs

• Mention monitoring export with URLs and dates
• Existing backlink list
• Brand names and product name variants

Method

1. Match mentions against the existing backlink list to isolate unlinked ones.
2. Verify each mention is live, on-topic, and in a linkable context.
3. Identify the most relevant destination URL for each mention.
4. Prioritise by publication relevance and recency.
5. Draft a short, specific request naming the sentence and the suggested destination.

Decision rules

• IF a mention is negative or critical → THEN route it to communications rather than sending a link request
• IF the mention is in a context where a link would be inappropriate → THEN skip it

Guardrails

• Never request links on critical coverage without communications approval
• Never send generic bulk requests
• Do not request links to pages irrelevant to the mention

Output

A prioritised request list: mention URL, suggested destination, and the drafted request.

Definition of done

• Existing links excluded
• Destination relevance checked
• Request references the specific sentence

Purpose

Generates story angles a journalist would cover, grounded in assets your business genuinely has.

Use when

At the start of a PR cycle.

Not for

Product announcements with no external interest.

Inputs

• Available proprietary data, expertise, and customer insight
• Target publications and their beats
• Brand claim rules

Method

1. Inventory what you have that others do not: data, access, experience, or a contrarian position.
2. For each asset, write the headline a journalist would run.
3. Test each headline against the publication's actual beat and recent coverage.
4. Identify what would have to be produced to support the story.
5. Discard angles requiring claims you cannot substantiate.

Decision rules

• IF an angle depends on a claim you cannot evidence → THEN discard it
• IF an angle has no publication whose beat it fits → THEN hold it for owned channels instead

Guardrails

• Never build angles on manufactured or exaggerated data
• Never pitch stories the business cannot substantiate on request
• Do not recycle an angle a target publication recently covered

Output

An angle list: asset, proposed headline, target publications, required production, and evidence status.

Definition of done

• Every angle tied to a real asset
• Publication fit checked
• Evidence status recorded

Purpose

Prepares a spokesperson's quotable material so journalist requests can be answered quickly and accurately.

Use when

Before a PR cycle, and when responding to journalist source requests.

Not for

Ghostwriting opinions the expert does not hold.

Inputs

• Spokesperson's areas of expertise and credentials
• Their actual positions on recurring questions
• Approval rules from SEO_CONTEXT

Method

1. List the questions journalists in this field repeatedly ask.
2. Capture the spokesperson's genuine position on each, in their words.
3. Write two quote lengths per position: one sentence and one paragraph.
4. Attach credentials and the evidence supporting each position.
5. Route the package for the spokesperson's own approval before use.

Decision rules

• IF a position has not been confirmed by the spokesperson → THEN leave it out of the package
• IF a question falls outside their expertise → THEN record it as out of scope and name who should answer

Guardrails

• Never attribute a position to a person who has not confirmed it
• Never claim credentials that cannot be verified
• Do not send quotes externally before approval

Output

An approved quote package: question, position, short and long quotes, credentials, and evidence.

Definition of done

• Every quote confirmed by the spokesperson
• Credentials verified
• Out-of-scope questions listed

Purpose

Writes a pitch a journalist can evaluate in fifteen seconds.

Use when

When an angle and its supporting asset are ready.

Not for

Angles without a finished supporting asset.

Inputs

• Approved angle and supporting asset
• Journalist's recent coverage
• Spokesperson availability and quotes

Method

1. Open with the finding or news, not with the company.
2. State in one line why this journalist's readers care now.
3. Provide the supporting evidence and how it can be verified.
4. Offer the specific next step: data access, interview, or embargo.
5. Keep the pitch to a length that fits on one screen.

Decision rules

• IF the angle requires context the journalist has not covered → THEN add one line of framing, not a background section
• IF the asset is not finished → THEN do not send the pitch

Guardrails

• Never overstate a finding to make the pitch stronger
• Never pitch without the asset ready to share
• Do not send identical pitches to competing publications simultaneously without saying so

Output

A pitch: subject line, opening finding, relevance line, evidence access, and offered next step.

Definition of done

• Finding stated first
• Verification path included
• Asset ready before sending

Purpose

Finds curated resource pages where your asset genuinely belongs, and prepares the submission.

Use when

When you have a resource that is objectively useful to a defined audience.

Not for

Promotional pages with no reference value.

Inputs

• Your resource asset and its audience
• Search patterns for resource pages in the topic
• Qualification criteria

Method

1. Locate resource pages covering the topic and audience your asset serves.
2. Check what each page already lists and whether your asset adds something absent.
3. Verify the page is maintained and its links are current.
4. Prepare a submission naming the gap your asset fills.
5. Record submissions so follow-up is not duplicated.

Decision rules

• IF a resource page already lists an equivalent asset → THEN skip it unless yours covers a documented gap
• IF a resource page has not been updated in years → THEN deprioritise it

Guardrails

• Never submit an asset that does not fit the page's stated purpose
• Never offer payment or reciprocal links for inclusion
• Do not submit the same asset repeatedly to the same page

Output

A submission list: page, its current coverage, the gap your asset fills, and the prepared message.

Definition of done

• Gap identified per page
• Maintenance status checked
• Submissions logged

Purpose

Finds dead references on relevant pages where your content is a genuine replacement.

Use when

When you hold content that matches a dead resource's subject.

Not for

Suggesting replacements that do not match the original.

Inputs

• Target pages in the topic area
• Their outbound link status
• Your inventory of matching content

Method

1. Identify relevant pages linking to dead resources.
2. Determine what the dead resource covered from context and archives.
3. Check whether your content genuinely covers the same subject at similar depth.
4. Prepare a message reporting the broken link and offering the replacement as an option.
5. Exclude cases where your content is not an honest equivalent.

Decision rules

• IF your content does not match the dead resource's subject → THEN report the broken link without proposing your page
• IF the dead resource has an official replacement → THEN point to that instead

Guardrails

• Never claim your content replaces a resource it does not match
• Never mass-send broken link messages without checking each case
• Do not misrepresent the original resource's content

Output

An opportunity list: page, dead link, original subject, match assessment, and prepared message.

Definition of done

• Original subject verified
• Match honestly assessed
• Non-matching cases handled without a pitch

Purpose

Explains how competitors earn links, so strategy targets the mechanism rather than individual domains.

Use when

Quarterly.

Not for

Copying a competitor's link list.

Inputs

• Competitor backlink exports with linking page context
• Competitor content and asset inventory
• Publication dates where available

Method

1. Classify each competitor's links by the asset or event that caused them.
2. Identify which assets earn links repeatedly rather than once.
3. Determine which mechanisms are reproducible for your business.
4. Estimate the production requirement for each reproducible mechanism.
5. Recommend one or two mechanisms to build a programme around.

Decision rules

• IF a mechanism depends on scale or funding you do not have → THEN exclude it and note why
• IF a mechanism relies on paid placements → THEN exclude it entirely

Guardrails

• Never replicate mechanisms that involve buying links
• Never assume a link was earned by content when it may be a partnership
• Do not report link counts without the mechanism behind them

Output

A mechanism analysis: mechanism, evidence, repeatability, production requirement, and recommendation.

Definition of done

• Links classified by cause
• Repeatable mechanisms separated
• Recommendation limited to two mechanisms

Purpose

Prevents third-party authority scores from driving decisions they cannot support.

Use when

Whenever a prospect list or report is built on vendor metrics.

Not for

Sites you have direct evidence about.

Inputs

• Prospect or report list with vendor metrics
• Metric definitions and their source
• Observable signals: traffic estimates, publishing activity, audience

Method

1. Record which vendor produced each score and what it measures.
2. Compare scores against observable signals for a sample of sites.
3. Flag sites where the score and the observable signals disagree.
4. Re-rank the list using observable signals as the primary criterion.
5. State the limitation of the metric in the report.

Decision rules

• IF a high-scoring site shows no genuine audience signals → THEN downgrade it and note the discrepancy
• IF a low-scoring site has a highly relevant audience → THEN keep it in the plan and explain why

Guardrails

• Never present a vendor score as an official ranking factor
• Never rank prospects on a single third-party metric
• Do not compare scores across different vendors

Output

A re-ranked list with vendor source, observable signals, discrepancies, and a stated metric limitation.

Definition of done

• Metric source named
• Sample verified against observable signals
• Limitation stated in the output

Purpose

Identifies legitimate industry directories, associations, and databases where a listing is appropriate.

Use when

When establishing a new brand's presence or entering a new market.

Not for

Low-quality directory submissions.

Inputs

• Business category and market
• Industry associations and databases in the sector
• Existing listing inventory

Method

1. List directories and databases used by the audience or industry, not by SEO tools.
2. Verify each is maintained and its listings are used by real visitors.
3. Check eligibility requirements and the information needed.
4. Prepare consistent listing information matching the brand fact sheet.
5. Record submissions and their status for future consistency checks.

Decision rules

• IF a directory accepts any submission without review → THEN exclude it
• IF a directory requires membership or accreditation → THEN route it to the business owner for a decision

Guardrails

• Never submit to directories that exist only to sell links
• Never submit inconsistent business information
• Do not create listings for locations or services that do not exist

Output

A listing plan: directory, eligibility, required information, submission status, and consistency check.

Definition of done

• Directories verified as genuinely used
• Information matches the brand fact sheet
• Submissions logged

Purpose

Finds the links that should already exist from existing business relationships.

Use when

Annually, and after signing new partners or customers.

Not for

Cold outreach to strangers.

Inputs

• List of partners, customers, integrations, suppliers, and sponsorships
• Existing backlink list
• Relationship owner per account

Method

1. List every existing relationship and check whether a link exists in either direction.
2. Identify pages where a mention would be natural: partner directories, case studies, integration pages.
3. Confirm each relationship allows public reference.
4. Route each opportunity to the relationship owner with a specific ask.
5. Track status and record where public reference is not permitted.

Decision rules

• IF a relationship is under a confidentiality agreement → THEN exclude it and record the restriction
• IF a partner page exists but omits your brand → THEN route a specific correction request to the relationship owner

Guardrails

• Never publish a customer or partner reference without permission
• Never approach partners directly without informing the relationship owner
• Do not imply relationships that are not current

Output

A relationship link map: account, link status both ways, natural placement, owner, and permission status.

Definition of done

• Permission verified per account
• Owner assigned per request
• Restrictions recorded

Purpose

Plans contributed articles that are worth publishing on their merits.

Use when

When you have expertise a publication's audience genuinely needs.

Not for

Mass guest posting for links.

Inputs

• Target publications and their contributor guidelines
• Available expertise and data
• Editorial calendar capacity

Method

1. Identify publications whose audience overlaps your ICP and that accept contributions.
2. Study their recent coverage to find the gap your expertise fills.
3. Propose a specific topic, not a general offer to write.
4. Confirm the piece can be written to their standard within capacity.
5. Define what the article gives the reader independently of any link.

Decision rules

• IF the topic is one your own site should own → THEN publish it yourself instead
• IF a publication accepts any contribution without editorial review → THEN exclude it

Guardrails

• Never submit content whose only purpose is a link
• Never publish the same article on multiple sites
• Do not pursue publications with no editorial standard

Output

A contribution plan: publication, audience fit, proposed topic, reader value, and capacity check.

Definition of done

• Audience overlap evidenced
• Topic specific to the publication
• Capacity confirmed

Purpose

Designs a research or data asset that publications have a reason to cite.

Use when

When you hold data others cannot access, or can collect it credibly.

Not for

Repackaging publicly available statistics.

Inputs

• Available proprietary data or collection capability
• Questions the market argues about
• Methodology and privacy constraints

Method

1. Identify the question your data can answer that no one else can.
2. Define the method, sample, and limitations before analysis.
3. Determine the finding formats a publication could cite directly.
4. Plan the supporting materials: methodology page, charts, and raw figures.
5. Set the update cadence if the asset is intended to become a reference.

Decision rules

• IF the data cannot support the intended claim → THEN narrow the claim to what the data shows
• IF the sample is too small to generalise → THEN state the limitation prominently or do not publish the finding

Guardrails

• Never publish findings the method cannot support
• Never omit sample size, method, or date
• Never publish data that identifies individuals or breaches privacy commitments

Output

A data asset specification: question, method, limitations, citable findings, supporting materials, and cadence.

Definition of done

• Method and limitations documented before analysis
• Findings match what the data supports
• Privacy review completed

Purpose

Recovers links lost to redirects, removed pages, or site changes.

Use when

Quarterly, and after any migration.

Not for

Acquiring new links.

Inputs

• Current backlink export with target URL status
• Previous backlink export for comparison
• Redirect map

Method

1. Identify backlinks pointing to URLs that are broken, redirected, or removed.
2. Group them by target and by cause.
3. Fix what you control: restore redirects or reinstate pages where appropriate.
4. For links removed at the source, verify the removal and decide whether to ask.
5. Prioritise by the linking page's relevance and reach.

Decision rules

• IF a backlink points to a 404 you created → THEN restore a redirect to the closest equivalent immediately
• IF a link was removed during a source-site redesign → THEN send a specific request referencing the original context

Guardrails

• Never redirect a linked URL to an unrelated page
• Never claim a link was removed without verifying against a prior export
• Do not chase links from sources that are no longer relevant

Output

A reclamation list: backlink, target status, cause, fix applied or request drafted, and priority.

Definition of done

• Every broken target grouped by cause
• Self-inflicted losses fixed first
• Requests reference specific context

Purpose

Writes the message sequence for a qualified prospect list without generic templates.

Use when

After prospects are qualified and an asset exists.

Not for

Unqualified or purchased lists.

Inputs

• Qualified prospect list with per-prospect angles
• The asset being offered
• Sending rules and volume limits

Method

1. Write the first message around the recipient's specific published work.
2. State what you are offering and why it fits that work in two sentences.
3. Define one follow-up only, with new information rather than a reminder.
4. Set the stop rule: no response after the follow-up ends the sequence.
5. Define the personalisation fields that must be filled per prospect.

Decision rules

• IF personalisation cannot be filled for a prospect → THEN remove them from the sequence
• IF a recipient declines → THEN stop immediately and record it

Guardrails

• Never send more than one follow-up
• Never use false urgency or fabricated familiarity
• Do not contact recipients who have declined or opted out

Output

A sequence: first message, single follow-up, personalisation fields, stop rules, and volume limits.

Definition of done

• Personalisation fields defined and fillable
• Stop rules stated
• Volume limits respected

Purpose

Reviews the pace and pattern of link acquisition to detect anomalies and set realistic expectations.

Use when

Quarterly.

Not for

Setting link quantity targets.

Inputs

• Backlink acquisition data over time
• Content and PR activity dates
• Competitor acquisition pattern if available

Method

1. Plot referring domain acquisition by month across the available history.
2. Mark the content, PR, and product events that coincide with movement.
3. Identify unexplained spikes and investigate their source.
4. Compare the pattern with the activity that produced it to find what works.
5. State what the pattern implies for planning, without projecting exact numbers.

Decision rules

• IF a spike has no matching activity → THEN investigate for scraper networks or unsolicited placements
• IF acquisition is flat despite activity → THEN review whether the assets are genuinely citable

Guardrails

• Never set link quantity targets as a primary objective
• Never assume a spike is positive without inspecting the sources
• Do not forecast link acquisition as a fixed number

Output

A velocity review: acquisition timeline, mapped activity, unexplained movement, and planning implications.

Definition of done

• Activity mapped to timeline
• Unexplained spikes investigated
• No numeric forecast presented

Purpose

Reviews inbound anchor text for patterns that look engineered rather than earned.

Use when

Quarterly, and after any outreach campaign.

Not for

Internal anchor review.

Inputs

• Backlink export with anchor text
• Target page mapping
• Historical anchor distribution if available

Method

1. Aggregate inbound anchors per target page and classify them by type.
2. Compare the distribution against what naturally earned links look like for the page type.
3. Flag exact-match concentrations and unnatural repetition.
4. Identify which campaigns or sources produced the concentration.
5. Recommend adjustments to future outreach rather than retroactive manipulation.

Decision rules

• IF exact-match anchors dominate a page's profile → THEN change future outreach practice and stop requesting anchors
• IF anchors come from a single network of sites → THEN investigate the source before taking any other action

Guardrails

• Never request specific anchor text in outreach
• Never attempt to manipulate existing anchors at scale
• Do not disavow links based on anchor distribution alone

Output

An anchor profile report: distribution by type and page, concentrations identified, sources, and practice changes.

Definition of done

• Distribution classified by type
• Sources of concentration identified
• Recommendations are forward-looking

Purpose

Provides a conservative process for reviewing suspicious links before considering any action.

Use when

When a manual action is received or a clear link scheme is discovered.

Not for

Routine housekeeping of ordinary low-quality links.

Inputs

• Backlink export
• Any manual action notice received
• History of past link-building activity

Method

1. Establish whether there is a documented problem: a manual action or evidence of a scheme.
2. If neither exists, stop and take no action.
3. If a problem exists, classify links by whether they were procured or unsolicited.
4. For procured links, attempt removal at the source and document each attempt.
5. Consider disavowal only after removal attempts, and document the reasoning.

Decision rules

• IF there is no manual action and no known scheme → THEN take no action and document the conclusion
• IF links were procured by a previous agency → THEN prioritise removal at the source before any disavowal

Guardrails

• Never disavow links speculatively
• Never use third-party toxicity scores as the basis for action
• Do not disavow links you did not procure without documented evidence of harm

Output

A review record: problem evidence, link classification, removal attempts, and the action decision with reasoning.

Definition of done

• Documented problem confirmed before any action
• Removal attempted before disavowal
• Decision reasoning recorded

Purpose

Scores a proposed story before production so effort goes to angles with genuine coverage potential.

Use when

Before committing production resources to a PR asset.

Not for

Evergreen content planning.

Inputs

• Proposed angle and supporting evidence
• Target publication beats
• Recent coverage of similar stories

Method

1. Score the angle on novelty, relevance to a current conversation, evidence strength, and audience size.
2. Check whether the same story has been covered recently and by whom.
3. Assess whether a journalist could write the story from the materials alone.
4. Produce a go, revise, or drop verdict with the deciding factor named.
5. For revise verdicts, state the specific change required.

Decision rules

• IF the story has been covered in the last quarter → THEN revise the angle or drop it
• IF a journalist would need to do additional research to write it → THEN add the missing materials before pitching

Guardrails

• Never score an angle without checking recent coverage
• Never inflate novelty by narrowing the claim beyond what the data supports
• Do not proceed with drop verdicts on stakeholder preference alone

Output

A score sheet: dimension scores, recent coverage check, verdict, deciding factor, and required revisions.

Definition of done

• Recent coverage checked
• Verdict states the deciding factor
• Revisions specified

Purpose

Designs a survey that produces defensible, citable findings.

Use when

When no existing data answers a question your market argues about.

Not for

Surveys designed to produce a predetermined conclusion.

Inputs

• The research question
• Available audience for sampling
• Privacy and consent requirements

Method

1. State the question and the hypotheses before writing any survey item.
2. Design questions that avoid leading wording and forced-choice bias.
3. Define the sample frame, target size, and how representativeness will be described.
4. Specify the analysis plan and the limitations to be published.
5. Plan the methodology page that will accompany every published finding.

Decision rules

• IF the achievable sample cannot support generalisation → THEN publish it as an indicative sample and label it clearly
• IF a question could be read as leading → THEN rewrite it before fielding

Guardrails

• Never write questions designed to produce a desired answer
• Never publish findings without sample size, method, and date
• Never collect personal data without consent and a stated purpose

Output

A survey specification: question, hypotheses, items, sample frame, analysis plan, limitations, and methodology page.

Definition of done

• Hypotheses stated before item writing
• Sample frame documented
• Limitations drafted before fielding

Purpose

Tracks earned coverage over time and connects it to the assets and pitches that produced it.

Use when

Monthly.

Not for

Tracking brand mentions inside AI answers; the AI visibility skills cover that.

Inputs

• Coverage monitoring export
• Pitch and asset log with dates
• Publication tiers or relevance classification

Method

1. Collect coverage for the period with publication, date, and link status.
2. Match each item to the pitch, asset, or event that likely produced it.
3. Separate earned coverage from syndication and republication.
4. Report coverage by publication relevance rather than by volume alone.
5. Identify which assets produced repeat coverage.

Decision rules

• IF coverage cannot be matched to any pitch or asset → THEN record it as unattributed rather than assigning it
• IF an item is syndicated from another publication → THEN count the original once and note the syndication

Guardrails

• Never count syndicated copies as separate coverage
• Never attribute coverage to a pitch without evidence
• Do not report coverage volume without relevance classification

Output

A coverage report: items with publication, date, link status, attributed source, and syndication notes.

Definition of done

• Syndication separated
• Attribution evidenced or marked unattributed
• Relevance classification applied

Purpose

Audits a business profile listing for completeness, accuracy, and consistency with the website.

Use when

Quarterly per location, and after any business change.

Not for

Managing customer reviews; separate skills cover that.

Inputs

• Current profile export or screenshots per location
• Website business information
• Brand fact sheet from SEO_CONTEXT

Method

1. Check every field for completeness and compare it against the website.
2. Verify name, address, phone, hours, and service descriptions match exactly.
3. Identify fields left empty that the business could legitimately complete.
4. Flag information that is outdated, duplicated, or inconsistent across locations.
5. Produce the correction list with the exact replacement values.

Decision rules

• IF profile information conflicts with the website → THEN designate the website as the source of truth unless the business says otherwise
• IF a field cannot be completed truthfully → THEN leave it empty rather than approximating

Guardrails

• Never enter keywords into the business name field
• Never list hours, services, or addresses that are not accurate
• Do not create profiles for locations without a genuine presence

Output

A per-location correction list: field, current value, required value, and source of truth.

Definition of done

• Every field compared against the website
• Corrections give exact values
• No speculative entries

Purpose

Chooses the primary and secondary listing categories that match what the business actually does.

Use when

At listing creation, and when services change.

Not for

Keyword targeting on the website.

Inputs

• Service list per location
• Available category taxonomy
• Competitor category choices where visible

Method

1. List the services each location genuinely delivers.
2. Match them to the closest available categories in the taxonomy.
3. Select one primary category reflecting the core service.
4. Add secondary categories only where the service is genuinely offered.
5. Document the reasoning so category changes can be reviewed later.

Decision rules

• IF no category exactly matches the service → THEN choose the closest accurate one rather than a broader popular one
• IF a competitor uses a category you do not qualify for → THEN do not copy it

Guardrails

• Never select categories for services the location does not provide
• Never change the primary category without recording the previous value and date
• Do not add categories purely because competitors use them

Output

A category assignment per location: primary, secondaries, reasoning, and previous values.

Definition of done

• Every category tied to a real service
• Primary category justified
• Change history recorded

Purpose

Defines the geographic area a location genuinely serves and how it is expressed across the site and listings.

Use when

For service-area businesses, and when coverage changes.

Not for

Businesses serving customers only at a physical address.

Inputs

• Actual service coverage by location
• Travel or delivery constraints
• Current declared service areas

Method

1. Establish the real coverage boundary from operational constraints, not ambition.
2. Express the boundary in the terms customers use: cities, regions, or postal areas.
3. Compare it against currently declared areas and flag overreach.
4. Define how coverage is presented on the site and in listings consistently.
5. Record the review date for coverage changes.

Decision rules

• IF a declared area exceeds actual coverage → THEN reduce the declaration and note the customer impact
• IF coverage differs by service → THEN declare it per service rather than as one boundary

Guardrails

• Never declare service areas the business cannot serve
• Never create separate pages for areas without genuine coverage
• Do not list every nearby town to widen apparent reach

Output

A service area definition per location: boundary, expression, corrections to current declarations, and review date.

Definition of done

• Boundary based on operational reality
• Overreach corrected
• Consistent expression across channels

Purpose

Specifies a location page that contains genuinely local information rather than a templated substitution.

Use when

When a location genuinely warrants its own page.

Not for

Generating pages for areas with no presence.

Inputs

• Location details, staff, and services
• Local proof: projects, customers, or partnerships
• Local query cluster

Method

1. Confirm the location has enough unique information to justify a page.
2. Specify the required unique content: local team, local proof, local service detail, and directions.
3. Define what is shared from the template and what must be written per location.
4. Specify local structured data and contact details.
5. Set the minimum unique content threshold below which no page is created.

Decision rules

• IF a location cannot meet the unique content threshold → THEN do not create the page; fold it into a regional page
• IF two locations share the same service and team → THEN create one page covering both

Guardrails

• Never publish location pages differing only by a place name
• Never claim a physical presence that does not exist
• Do not duplicate service descriptions across location pages

Output

A location page specification: required unique content, shared elements, structured data, and the threshold rule.

Definition of done

• Threshold applied before creation
• Unique content specified per location
• No template-substitution pages

Purpose

Builds the query set for a location using local phrasing and real service demand.

Use when

Before building or refreshing local pages.

Not for

National keyword research.

Inputs

• Service list for the location
• Local language and naming conventions
• Demand evidence where available

Method

1. Collect the terms locals use for the service, including regional variations.
2. Combine services with location names in the patterns people actually type.
3. Separate queries where the searcher wants a nearby provider from research queries.
4. Map each query to the page that should serve it.
5. Flag queries with no supporting page and no plan.

Decision rules

• IF a query uses a regional term unfamiliar elsewhere → THEN use the local term on the local page only
• IF a query is research-oriented → THEN map it to national content rather than the location page

Guardrails

• Never invent local search volumes
• Never use place names the local audience does not use
• Do not map research queries to location pages

Output

A local query map: query, local phrasing note, intent, mapped page, and gaps.

Definition of done

• Local phrasing verified
• Intent separated
• Gaps listed

Purpose

Turns review text into operational themes rather than a star average.

Use when

Monthly per location.

Not for

Responding to individual reviews.

Inputs

• Review export with text, rating, and date
• Location and service mapping
• Prior period themes for comparison

Method

1. Extract the specific subject of each review comment, positive and negative.
2. Group comments into recurring themes and count their frequency.
3. Compare theme frequency against the previous period.
4. Identify themes tied to a specific location, staff group, or service.
5. Route each theme to the owner who can act on it.

Decision rules

• IF a negative theme grows across two periods → THEN escalate it as an operational issue rather than a review problem
• IF a theme appears at one location only → THEN route it to that location's manager

Guardrails

• Never summarise reviews as a single score
• Never attribute reviews to named individuals in a published report
• Do not generalise a single review into a theme

Output

A theme report per location: theme, frequency, trend, example excerpts, and assigned owner.

Definition of done

• Themes derived from text, not ratings
• Trend comparison included
• Owners assigned

Purpose

Drafts responses that address the specific issue raised without templated language.

Use when

For every review requiring a response.

Not for

Disputing a customer's account of events.

Inputs

• Review text, rating, and date
• Known facts about the visit or order
• Response policy and approval rules

Method

1. Identify the specific issue or compliment in the review.
2. Acknowledge it in the reviewer's own terms without repeating a stock phrase.
3. State what will happen next where an action is warranted.
4. Route responses involving disputed facts or compensation to the approval owner.
5. Keep the response shorter than the review.

Decision rules

• IF a review alleges something you cannot verify → THEN acknowledge, offer a direct channel, and do not dispute publicly
• IF a review appears fraudulent → THEN route it to the reporting process rather than responding with accusations

Guardrails

• Never dispute a customer's experience publicly
• Never disclose personal or order details in a public response
• Never offer compensation without approval

Output

A drafted response per review with the identified issue, the action stated, and the approval flag.

Definition of done

• Issue addressed specifically
• No personal details disclosed
• Approval flags applied

Purpose

Checks that the business appears identically across the directories and databases that carry its details.

Use when

Quarterly, and after any address, name, or phone change.

Not for

Finding new directories to submit to.

Inputs

• Master business information from SEO_CONTEXT
• Existing citation inventory
• Current values found on each platform

Method

1. Compare each platform's listing field by field against the master record.
2. Record every discrepancy with its exact current value.
3. Prioritise discrepancies in name, address, and phone above other fields.
4. Identify listings that cannot be edited and note the escalation path.
5. Produce the correction queue with platform-specific instructions.

Decision rules

• IF a discrepancy exists in the address or phone → THEN treat it as high priority regardless of the platform's traffic
• IF a listing cannot be claimed → THEN record the escalation path rather than leaving it unresolved

Guardrails

• Never guess which version of the information is correct
• Never create duplicate listings to bypass an unclaimable one
• Do not correct listings without the verified master record

Output

A discrepancy queue: platform, field, current value, correct value, priority, and access status.

Definition of done

• Master record verified first
• Every discrepancy recorded exactly
• Access status noted per platform

Purpose

Finds where the business name, address, or phone number varies across the website itself.

Use when

Before a citation cleanup, and after rebranding or relocation.

Not for

Third-party platform listings.

Inputs

• Crawl export including footer, contact, and location page content
• Master business information
• Structured data output

Method

1. Extract every instance of name, address, and phone from the site.
2. Compare each against the master record, including formatting.
3. Check structured data values against the visible values.
4. Identify templates producing the inconsistency rather than individual pages.
5. Specify the single source the site should render these values from.

Decision rules

• IF formatting differs but the data is correct → THEN standardise formatting and note it as low risk
• IF structured data conflicts with visible content → THEN treat it as high priority

Guardrails

• Never correct site data before confirming the master record
• Never leave structured data and visible content in conflict
• Do not fix individual pages when a template is the cause

Output

A discrepancy report: location on site, current value, correct value, template cause, and priority.

Definition of done

• Structured and visible values compared
• Template causes identified
• Single source specified

Purpose

Compares your local presence against the businesses actually appearing for your local queries.

Use when

Quarterly per priority location.

Not for

National competitive analysis.

Inputs

• Local query list and observed local results
• Competitor profile and website information
• Your own local presence data

Method

1. Record which businesses appear for the priority local queries.
2. Compare profile completeness, category selection, review volume, and local content.
3. Identify what those businesses have that you do not, factually.
4. Separate factors you can act on from those you cannot.
5. Produce the actionable difference list per location.

Decision rules

• IF a competitor's advantage is proximity to the searcher → THEN record it as non-actionable and focus on the rest
• IF a competitor has substantially more local content → THEN prioritise the content gap

Guardrails

• Never fabricate competitor review counts or profile details
• Never recommend fake reviews or fake locations to compete
• Do not treat proximity factors as failures to fix

Output

A local comparison per location: competitors present, factual differences, actionable items, and priorities.

Definition of done

• Observations recorded, not assumed
• Actionable and non-actionable separated
• Priorities per location

Purpose

Designs the URL and page structure for a business with many locations.

Use when

Before launching multiple locations, or when the current structure is inconsistent.

Not for

Single-location businesses.

Inputs

• Location inventory with services per location
• Current URL structure
• Growth plan for new locations

Method

1. Define the hierarchy: country, region, city, and location, using only the levels the business needs.
2. Specify the URL pattern and how new locations slot into it.
3. Define which content lives at each level to avoid duplication.
4. Specify the internal link contract between levels.
5. Define the process for adding and retiring a location.

Decision rules

• IF a region has one location → THEN skip the regional level rather than creating a page with one child
• IF services differ by location → THEN hold service content at the location level, not the regional level

Guardrails

• Never create hierarchy levels with a single child page
• Never duplicate identical service copy across every location page
• Do not leave the location retirement process undefined

Output

An architecture specification: hierarchy, URL patterns, content allocation by level, link contract, and lifecycle process.

Definition of done

• Hierarchy justified by location count
• Content allocation prevents duplication
• Lifecycle process defined

Purpose

Sets the rules controlling what individual locations may change and what stays centrally managed.

Use when

For franchises and multi-location brands.

Not for

Single-location businesses.

Inputs

• Location list with ownership model
• Current inconsistencies across locations
• Brand and legal requirements

Method

1. Define which elements are centrally controlled and which are location-editable.
2. Write the standard for each location-editable element with examples.
3. Define the approval path for exceptions.
4. Specify the audit cadence and who performs it.
5. Provide the onboarding checklist for a new location.

Decision rules

• IF a location requests an exception to a central rule → THEN route it through the documented approval path, not local judgement
• IF an element causes recurring inconsistency → THEN move it to central control

Guardrails

• Never leave brand-critical fields editable without a standard
• Never allow locations to alter legally required information
• Do not write rules without an audit mechanism

Output

A governance document: control matrix, standards with examples, approval path, audit cadence, and onboarding checklist.

Definition of done

• Every element assigned to central or local control
• Standards include examples
• Audit cadence defined

Purpose

Specifies structured data for locations that matches the visible page content.

Use when

When building or auditing location pages.

Not for

Marking up locations without dedicated pages.

Inputs

• Location page content
• Verified business details
• Current markup if present

Method

1. Map each required property to a visible element on the location page.
2. Specify address, contact, hours, and area served using verified values.
3. Exclude properties the page does not display.
4. Ensure consistency with the profile listing and the site's NAP data.
5. Specify how markup updates when hours or details change.

Decision rules

• IF a property has no visible equivalent on the page → THEN add the content or omit the property
• IF hours vary seasonally → THEN specify how exceptions are represented rather than omitting them

Guardrails

• Never mark up information not visible on the page
• Never mark up aggregate ratings the page does not display
• Do not leave markup static when the underlying data changes

Output

A markup specification per location template: property mapping, exclusions, consistency checks, and update rules.

Definition of done

• Every property mapped to visible content
• Consistency with listings verified
• Update mechanism defined

Purpose

Reviews local map visibility across the service area and identifies the factors within your control.

Use when

Quarterly per priority location.

Not for

Guaranteeing map placement.

Inputs

• Observed local results across sample points in the service area
• Profile completeness and review data
• Competitor presence data

Method

1. Record observed visibility across multiple sample points rather than from one location.
2. Compare visibility patterns against distance from the business address.
3. Identify controllable factors: profile completeness, categories, reviews, and local content.
4. Separate them from uncontrollable factors such as proximity.
5. Recommend actions on controllable factors only.

Decision rules

• IF visibility drops consistently with distance → THEN record it as expected and focus on controllable factors
• IF visibility is weak near the address → THEN prioritise profile and category review

Guardrails

• Never claim a specific map position can be guaranteed
• Never recommend creating listings at addresses you do not occupy
• Do not draw conclusions from observations at a single point

Output

A visibility review: sample-point observations, distance pattern, controllable factors, and recommended actions.

Definition of done

• Multiple sample points used
• Controllable factors isolated
• No placement guarantees

Purpose

Builds location-specific answers to the questions customers actually ask before visiting or calling.

Use when

When location pages lack practical information.

Not for

Generic company FAQs.

Inputs

• Questions from calls, messages, and reviews per location
• Verified operational details
• Location page content

Method

1. Collect the questions each location actually receives.
2. Separate questions with location-specific answers from those with company-wide answers.
3. Write concise, verified answers for location-specific questions.
4. Place them on the location page, not the company FAQ.
5. Set a review cadence tied to operational changes.

Decision rules

• IF a question has the same answer at every location → THEN move it to the company FAQ and link from the location page
• IF an answer depends on details that change often → THEN state the source rather than a fixed value

Guardrails

• Never publish operational details that have not been verified with the location
• Never duplicate the same FAQ block across all location pages
• Do not answer questions the location cannot commit to

Output

A location FAQ set: questions, verified answers, placement, and the review cadence.

Definition of done

• Questions sourced from real enquiries
• Answers verified with the location
• Company-wide questions separated

Purpose

Finds content topics that are genuinely local rather than a national topic with a place name added.

Use when

When location pages need supporting content.

Not for

National topic planning.

Inputs

• Local market characteristics and regulations
• Local customer questions and projects
• Local events and partnerships

Method

1. Identify what differs about the service in this location: regulations, conditions, pricing structures, or seasons.
2. Collect local proof: projects, customers, partnerships, and events.
3. Generate topics that only this location could write credibly.
4. Discard topics that would read identically for another city.
5. Map each surviving topic to a local query where demand exists.

Decision rules

• IF a topic would read identically with another place name substituted → THEN discard it
• IF a topic is credible but has no local search demand → THEN keep it for the location page rather than a standalone article

Guardrails

• Never produce location content by substituting place names
• Never reference local projects or customers without permission
• Do not claim local expertise the location does not have

Output

A local topic list: topic, what makes it location-specific, supporting proof, and mapped query.

Definition of done

• Substitution test applied to every topic
• Proof identified
• Query mapping recorded

Purpose

Finds duplicate or outdated listings that split visibility and confuse customers.

Use when

Quarterly, and after moves, rebrands, or acquisitions.

Not for

Creating new listings.

Inputs

• Listing inventory across platforms
• Historical addresses, names, and phone numbers
• Current verified location list

Method

1. Search each platform for all listings matching the brand, its former names, and its addresses.
2. Identify duplicates, outdated entries, and listings for closed locations.
3. Determine which listing should be retained per location.
4. Specify the resolution per duplicate: merge, mark closed, or request removal.
5. Record ownership and access status for each.

Decision rules

• IF two listings exist for the same location → THEN retain the one with the established history and merge the other
• IF a listing exists for a closed location → THEN mark it closed rather than deleting it

Guardrails

• Never delete a listing with established review history without merging
• Never leave closed locations listed as open
• Do not create a new listing to replace a duplicate you cannot access

Output

A duplicate register: platform, listings found, retained listing, resolution action, and access status.

Definition of done

• Former names and addresses searched
• Retained listing chosen per location
• Actions specified per duplicate

Purpose

Checks that a local visitor can complete the action they came for without friction.

Use when

On location pages with visibility but few calls, bookings, or visits.

Not for

National conversion optimisation.

Inputs

• Location page content and layout
• Available contact and booking methods
• Enquiry data if available

Method

1. Confirm the primary local actions are visible without scrolling on mobile.
2. Verify phone numbers, booking links, and directions work and reach the right location.
3. Check that hours, parking, and access information are present and current.
4. Identify friction: forms requiring unnecessary fields or missing contact options.
5. Specify the changes required, ordered by the action they unblock.

Decision rules

• IF a phone number routes to a central line without location context → THEN recommend location routing or an explicit note
• IF hours or access details are missing → THEN treat it as a blocking gap rather than an enhancement

Guardrails

• Never publish contact routes that have not been tested
• Never claim conversion improvements without measurement
• Do not remove accessibility information to simplify a page

Output

A readiness audit: action, current state, tested result, friction found, and required changes.

Definition of done

• Contact routes tested
• Practical details verified
• Changes ordered by unblocked action

Purpose

Plans a sustainable cadence of listing updates that carry genuine information.

Use when

When listing updates are sporadic or purely promotional.

Not for

Website content planning.

Inputs

• Location activity: offers, events, changes, and news
• Posting capacity per location
• Brand and claim rules

Method

1. Identify the categories of update the business genuinely produces.
2. Set a cadence each location can sustain without inventing content.
3. Define the required elements per update: subject, detail, and next step.
4. Assign ownership per location and a review step for claims.
5. Define what to do when there is nothing genuine to post.

Decision rules

• IF a location has no genuine update in the period → THEN skip the post rather than publishing filler
• IF an update contains a pricing or availability claim → THEN route it through the review step first

Guardrails

• Never publish promotional claims that have not been reviewed
• Never post content that misrepresents availability or pricing
• Do not set a cadence the locations cannot sustain

Output

An update plan: categories, cadence, required elements, owners, review step, and the skip rule.

Definition of done

• Cadence matched to capacity
• Ownership assigned
• Skip rule stated

Purpose

Identifies local organisations and events where genuine involvement earns visibility and links.

Use when

When building local authority for a location.

Not for

Buying placements on unrelated local directories.

Inputs

• Location and its community context
• Existing local relationships and memberships
• Budget and involvement capacity

Method

1. List local organisations, associations, events, and institutions relevant to the business.
2. Identify where the business already has a genuine relationship.
3. Assess which involvements are realistic given capacity and budget.
4. Prepare the specific approach per opportunity, naming the contribution offered.
5. Record outcomes and the resulting visibility.

Decision rules

• IF an opportunity requires payment with no genuine involvement → THEN treat it as advertising and evaluate it as such
• IF an existing relationship has no public reference → THEN start there before pursuing new ones

Guardrails

• Never buy links disguised as sponsorships
• Never claim community involvement that is not genuine
• Do not pursue opportunities the business cannot honour

Output

An opportunity list: organisation, relationship status, contribution offered, capacity check, and outcome.

Definition of done

• Existing relationships checked first
• Capacity verified
• Paid placements classified as advertising

Purpose

Builds the standing set of prompts that represent how buyers actually ask AI systems about your category.

Use when

Before any AI visibility measurement begins, then reviewed quarterly.

Not for

Traditional keyword research.

Inputs

• ICP definition and buyer problems from SEO_CONTEXT
• Real questions from sales, support, and search data
• Category and competitor names

Method

1. Write prompts in the phrasing buyers use with an assistant, not in keyword form.
2. Cover five types: category discovery, comparison, problem-solving, brand-specific, and validation.
3. Include prompts where your brand should appear and prompts where it plausibly should not.
4. Fix the wording of each prompt so results stay comparable over time.
5. Assign each prompt a priority tier and a review date.

Decision rules

• IF a prompt returns a different subject each time it is run → THEN rewrite it until it is stable enough to compare
• IF a prompt names your brand only → THEN keep it in the brand tier and do not count it as category visibility

Guardrails

• Never treat prompts as keywords or attach search volume to them
• Never change prompt wording mid-cycle without recording the change
• Do not build a prompt set only from prompts you expect to win

Output

A prompt universe: prompt text, type, priority tier, market, language, and review date.

Definition of done

• All five prompt types represented
• Wording locked and versioned
• Prompts where you should not appear included

Purpose

Checks whether [BRAND] appears in AI answers for a defined prompt set, and records how it appears.

Use when

On a fixed recurring cadence against the prompt universe.

Not for

Measuring website rankings.

Inputs

• Prompt universe with locked wording
• Engines to be checked
• Brand names and product name variants

Method

1. Run each prompt on each engine using the locked wording and record the full answer.
2. Record for each answer whether the brand is mentioned, cited with a link, or absent.
3. Record the position of the mention within the answer and its context.
4. Note which competitors appear in answers where you do not.
5. Store the raw answer text with the date and engine for later comparison.

Decision rules

• IF the brand is mentioned without a citation → THEN record it as a mention, not a citation, and note the distinction
• IF an answer varies between runs of the same prompt → THEN record both runs rather than choosing one

Guardrails

• Never report a mention you have not captured in raw output
• Never combine results from different engines into one figure without labelling them
• Do not paraphrase answers in the record; store what was returned

Output

A mention log: prompt, engine, date, mention status, citation status, position, context, and competitors present.

Definition of done

• Every prompt run on every listed engine
• Raw answers stored with dates
• Mentions and citations recorded separately

Purpose

Identifies which sources AI answers cite for your priority prompts, and who controls them.

Use when

Monthly, after the mention check.

Not for

Analysing your own site's backlinks.

Inputs

• Captured answers with their cited sources
• Prompt universe with tiers
• Competitor and own domain lists

Method

1. Extract every cited source from the captured answers.
2. Classify each source: own site, competitor, publisher, community, directory, or institution.
3. Count citation frequency by source and by prompt type.
4. Identify the sources cited across many prompts, which act as category references.
5. Note which sources you can influence, contribute to, or only observe.

Decision rules

• IF a source is cited across many prompts → THEN treat it as a category reference and prioritise presence on it
• IF a source is a competitor's own content → THEN record it and route it to the content gap analysis

Guardrails

• Never claim a source influences an engine's answers beyond what the citations show
• Never fabricate a citation list from expectation
• Do not treat a single citation as a pattern

Output

A source register: source, type, citation count, prompts cited on, influence level, and access path.

Definition of done

• Sources extracted from captured answers only
• Classification applied
• Influence level assigned

Purpose

Tracks which competitors appear in AI answers for your prompt set and how they are described.

Use when

Monthly.

Not for

Traditional competitive rank tracking.

Inputs

• Captured answers across the prompt set
• Competitor list from SEO_CONTEXT
• Previous period's competitor record

Method

1. Extract every brand named in each answer, including brands not on your competitor list.
2. Count appearance frequency by competitor and by prompt type.
3. Record the attributes each competitor is credited with.
4. Compare against the previous period to identify entrants and drop-offs.
5. Flag brands appearing frequently that are not currently tracked as competitors.

Decision rules

• IF an unlisted brand appears frequently → THEN add it to the tracked set and inform the business
• IF a competitor is credited with an attribute you also have → THEN route it to the brand fact and content skills

Guardrails

• Never assume a named brand is a competitor without confirming with the business
• Never report competitor frequency without stating the prompt set used
• Do not compare periods that used different prompt wording

Output

A competitor appearance report: brand, frequency, prompt types, credited attributes, and period change.

Definition of done

• All named brands extracted
• Attributes recorded verbatim
• Prompt set and wording version stated

Purpose

Compares how different engines answer the same prompt, and what that reveals about source preference.

Use when

Monthly, on the priority prompt tier.

Not for

Deciding which engine is best.

Inputs

• Captured answers for the same prompts across engines
• Cited sources per answer
• Prompt tier definitions

Method

1. Place answers to the same prompt side by side by engine.
2. Compare which brands, sources, and claims each includes.
3. Identify claims present in one engine's answer and absent in others.
4. Note structural differences: list versus narrative, cited versus uncited.
5. Summarise where your visibility differs by engine and what sources explain it.

Decision rules

• IF one engine cites you and others do not → THEN examine the source it cites and whether the others reference it
• IF engines disagree on a factual claim about your brand → THEN route it to the brand fact consistency skill

Guardrails

• Never average results across engines into a single score without showing the components
• Never assume engines share the same source coverage
• Do not draw conclusions from a single prompt

Output

A comparison matrix: prompt, engine, brands present, sources cited, claims, and structural notes.

Definition of done

• Same prompt wording used across engines
• Differences named specifically
• Conclusions based on multiple prompts

Purpose

Turns the captured measurements into a stable scorecard that can be compared period to period.

Use when

Monthly, after collection is complete.

Not for

Replacing the underlying measurement.

Inputs

• Mention log for the period
• Citation and competitor records
• Prompt universe version

Method

1. Define the metrics: mention rate, citation rate, competitor co-occurrence, and prompt coverage.
2. Calculate each metric per engine and per prompt tier separately.
3. State the prompt universe version and any changes since the last period.
4. Compare against the previous period only where the prompt set is unchanged.
5. Note the sample size behind every figure.

Decision rules

• IF the prompt set changed since the last period → THEN report the new baseline and do not present a trend
• IF a metric is based on fewer than ten prompts → THEN report it with the sample size and mark it indicative

Guardrails

• Never present a blended score without its components
• Never compare periods with different prompt sets
• Do not report percentages without the underlying counts

Output

A scorecard: metrics by engine and tier, sample sizes, prompt version, and period comparison where valid.

Definition of done

• Sample sizes shown
• Prompt version recorded
• Invalid comparisons suppressed

Purpose

Finds the sources cited for your priority prompts where your brand is absent but could legitimately be present.

Use when

Monthly, after source analysis.

Not for

Generic link prospecting.

Inputs

• Source register with citation frequency
• Your presence status on each source
• Contribution and inclusion rules per source

Method

1. List frequently cited sources where your brand is not present.
2. Determine how presence is obtained on each: listing, contribution, review, or editorial coverage.
3. Assess eligibility and effort per source honestly.
4. Rank sources by citation frequency across priority prompts and by feasibility.
5. Assign each source an owner and a route to presence.

Decision rules

• IF a source requires editorial coverage → THEN route it to the digital PR skills rather than treating it as a listing task
• IF a source excludes your category or business type → THEN record it as unavailable and move on

Guardrails

• Never attempt to manipulate a source's content to insert your brand
• Never buy placements on sources presented as neutral references
• Do not claim eligibility you have not verified

Output

A gap list: source, citation frequency, presence route, eligibility, effort, owner, and priority.

Definition of done

• Presence route identified per source
• Eligibility verified
• Ownership assigned

Purpose

Assesses which cited sources carry the most influence across your prompt set, so effort is not spread evenly.

Use when

Quarterly.

Not for

Judging a source's SEO authority metrics.

Inputs

• Source register with citation counts
• Prompt tier and engine breakdown
• Source characteristics: type, update frequency, editorial model

Method

1. Rank sources by citation frequency weighted by prompt priority.
2. Identify sources cited across multiple engines rather than one.
3. Record each source's update frequency and editorial model.
4. Separate sources that reflect consensus from those that create it.
5. Recommend the three sources where presence would affect the most priority prompts.

Decision rules

• IF a source is cited by one engine only → THEN rank it below cross-engine sources of similar frequency
• IF a source aggregates other sources → THEN trace the upstream source and evaluate that instead

Guardrails

• Never equate citation frequency with editorial quality
• Never rank sources on third-party authority metrics alone
• Do not recommend more than three focus sources per cycle

Output

A weighted source ranking with cross-engine presence, editorial model, upstream tracing, and three focus recommendations.

Definition of done

• Weighting method stated
• Cross-engine presence recorded
• Focus limited to three sources

Purpose

Checks whether AI answers describe your brand accurately and consistently with your own approved facts.

Use when

Monthly, and immediately after any positioning or product change.

Not for

Correcting competitor descriptions.

Inputs

• Approved brand fact sheet from SEO_CONTEXT
• Captured answers mentioning the brand
• Public sources describing the brand

Method

1. Extract every factual claim made about your brand in the captured answers.
2. Compare each against the approved fact sheet.
3. Classify each as accurate, outdated, incomplete, or incorrect.
4. Trace incorrect claims to the public sources most likely carrying them.
5. Specify the corrections needed at the source, not at the engine.

Decision rules

• IF a claim is outdated → THEN identify which public source still carries the old information and correct it there
• IF a claim is incorrect and traceable to your own site → THEN prioritise the on-site correction immediately

Guardrails

• Never attempt to correct an engine's output directly
• Never publish corrections that conflict with the approved fact sheet
• Do not assume the source of an incorrect claim without evidence

Output

A fact audit: claim, engine, classification, likely source, and the correction action with owner.

Definition of done

• Every claim classified
• Sources traced or marked unknown
• Corrections targeted at sources

Purpose

Assesses whether a page can be read, understood, and used as a source by an AI assistant.

Use when

Before publishing key pages, and when a page fails to earn citations.

Not for

Traditional on-page ranking review.

Inputs

• Page content and structure
• Target prompts the page should serve
• Entity register and fact sheet

Method

1. Check whether the page states its subject, scope, and audience explicitly.
2. Verify each section answers one question completely and independently.
3. Check that claims carry sources, dates, and methods where relevant.
4. Confirm entity names match the register and are used consistently.
5. Test whether the page's key passages make sense when read alone.

Decision rules

• IF a passage requires the surrounding page to make sense → THEN rewrite it to stand alone
• IF a claim has no attributable source → THEN add the source or remove the claim

Guardrails

• Never claim a page will be cited as a result of these changes
• Never add unsupported claims to appear more authoritative
• Do not restructure a page that is already cited without recording the before state

Output

A readiness report: criterion, current state, required change, and a before-state record.

Definition of done

• All five criteria assessed
• Changes specified per criterion
• Before state recorded

Purpose

Examines how a page divides into self-contained chunks and whether each chunk carries enough context.

Use when

On long reference pages intended to be cited.

Not for

Short single-answer pages.

Inputs

• Page content with heading structure
• Target questions per section
• Entity naming rules

Method

1. Divide the page at its heading boundaries and treat each section as a standalone unit.
2. Check whether each unit names its subject rather than relying on the page title.
3. Flag units whose meaning depends on a table, image, or list elsewhere.
4. Ensure defined terms are introduced within the unit or linked.
5. Rewrite the opening sentence of each unit to carry its subject and claim.

Decision rules

• IF a unit depends on a table located in another section → THEN restate the key figures within the unit or move the table
• IF a unit is shorter than two sentences → THEN merge it with an adjacent unit

Guardrails

• Never repeat the entire page context in every section
• Never split content into fragments to increase the number of chunks
• Do not remove tables or lists that carry the information

Output

A chunk review: unit, self-containment verdict, dependency, and the rewritten opening sentence.

Definition of done

• Every unit assessed
• Dependencies named
• Openings carry subject and claim