The SEO playbooks

What an experienced SEO checks before changing a page. The agents read these before they act, and the audit and priority reports link their advice back to them. Guidance, not search-engine rules.

These notes are what an experienced SEO would check before changing a page. They are guidance, not rules of the search engines: where a statement depends on how search engines currently behave, it says so. Always prefer Google's own documentation (Search Central) over this summary, and verify with your own data before acting.

The drafting agent reads these before it writes or edits a page, and the audit, insights and priority reports link their advice back to them.

PlaybookUse it when
Search intent and page typeschoosing what a page should be and whether it matches the query
Titles, descriptions and click-througha page ranks but does not get clicks
Technical SEO checklistauditing crawling, indexing, canonicals and speed
Cannibalisation and consolidationtwo pages compete for one query
Topical authority and internal linkingplanning a cluster or fixing weak internal links
Content quality, E-E-A-T and spam policieswriting or reviewing any page; staying clear of penalties
Structured dataadding or fixing schema markup
Refreshing, merging and pruninga page lost visibility, or you have thin or overlapping pages
Redirects, canonicals and migrationschanging URLs, moving content, retiring pages
AI search visibilitybeing understood and cited by AI answers
Measuring and experimentsjudging whether a change worked
Keyword research and clusteringchoosing topics and grouping queries
Content briefs and draftingwriting the brief and the page
Editorial review checklistreviewing a draft before it merges
Audit fix recipesfixing a specific finding from the technical audit
Indexing and crawl diagnosispages are missing from the index, or Search Console shows "not indexed"
Recipe: consent banneranalytics loads before consent, or the consent job reports a finding
Recipe: conversion trackingGA4 shows visits but no leads, or conversions are not marked as key events
Local SEOthe business serves a place: profile, listings, location pages
Link building and digital PRearning links honestly, and staying clear of link schemes
SEO reportingwriting an honest report the owner can act on
Working on any kind of websitethe site is WordPress, Shopify, a framework, a static site or a hosted builder
International and multilingual SEOthe site serves more than one language or country
Ecommerce SEOcategory, product and faceted-navigation pages
Competitor analysislearning from who ranks above you, honestly
Images, video and mediaalt text, formats, sizes, video and previews
Entity, brand and reputationbeing recognised, trusted and described correctly
AI search visibility

AI answers (assistants, AI overviews, chat search) summarise and cite web pages. How they choose sources is not fully documented and changes often, so treat everything here as practice that tends to help, not a guarantee, and be wary of anyone selling certainty.

What tends to help

  • Be a good search result first. Many AI features draw on pages that already rank and are indexed, so the basics (crawlable, indexable, useful, trustworthy) come first.
  • Put the answer up front. A clear, self-contained answer in the opening paragraph, with supporting detail below, is easy to quote accurately. Use question-style headings that match how people ask.
  • Make content extractable. Short paragraphs, descriptive headings, lists and tables for comparisons or steps, and definitions stated plainly.
  • Serve content in the initial HTML. Many AI crawlers do not run JavaScript. If your page text only appears after scripts run, they may see an almost empty page. Server-side or static rendering fixes this.
  • Be explicit about entities. Say who you are, what you do and where, consistently across the site, with Organization and Person structured data and real sameAs profiles.
  • Cite and be citable. Link to primary sources; publish original facts, data, definitions and examples others will reference. Keep them accurate and dated.
  • Keep it fresh and honest. Outdated or contradictory pages get ignored or misquoted.

Crawler access

  • Check your robots.txt: some AI crawlers use their own user agents. Decide deliberately whether to allow them; blocking removes you from those answers, allowing lets your content be used.
  • llms.txt is a proposed convention for pointing AI systems at your key pages. It is not a standard that search engines are known to rely on, so treat it as low-cost and unproven rather than a lever.

Measuring

  • There is no official report for "AI citations" in Search Console. Watch for referral traffic from AI products in your analytics, and spot-check by asking the assistants your target questions and noting whether you are cited and whether they get the facts right.
  • Track brand searches over time; AI exposure can show up there.

Avoid

  • Writing for machines at the expense of readers.
  • Fabricated "expert quotes" or statistics designed to be cited.
  • Mass-produced pages made only to appear in answers: that is scaled content abuse, which risks your normal rankings too.
Audit fix recipes

What to actually do about each finding in the technical audit. Rule names match the audit report. Always fix the cause, not just the symptom, and re-run the audit after.

Crawling and indexing

  • status-error: a sitemap URL that errors. Restore the page, redirect it to its replacement with a single 301, or remove it from the sitemap. Never leave a 404 in the sitemap.
  • status-redirect / redirect-chain / link-to-redirect: list the final URL in the sitemap and in internal links. Collapse chains so the old URL redirects straight to the destination in one hop.
  • noindex-in-sitemap: decide. If the page should rank, remove noindex; if not, remove it from the sitemap.
  • robots-blocked / robots-blocks-all: allow the path in robots.txt. A blocked page cannot have its content or noindex read. A site-wide Disallow: / is almost always a leftover staging rule.
  • sitemap-not-in-robots: add a Sitemap: line with the absolute sitemap URL.
  • orphan: add links from at least one hub page and two related pages, using descriptive anchor text. An orphan relies on the sitemap alone.
  • deep: link important pages from the home page or a main hub so they are within three clicks.

Canonicals and duplicates

  • canonical-missing: add a self-referencing canonical with the absolute, final URL.
  • canonical-other: confirm it is intentional. If this page should rank, point the canonical at itself.
  • canonical-broken: the canonical target errors, redirects or is noindex. Point it at a live, indexable page.
  • title-duplicate / desc-duplicate / h1-duplicate / duplicate-content: make each page distinct for its own query, or consolidate pages that serve the same intent and redirect the loser (cannibalisation playbook).

On-page

  • title-missing / title-long / title-short: one unique title per page, topic first, about 50 to 60 characters.
  • desc-missing / desc-long / desc-short: a unique summary of what the reader gets, about 120 to 155 characters. Search engines may rewrite it.
  • h1-missing / h1-multiple: one H1 stating the page topic.
  • h1-long: put the topic in the first words and keep the H1 to about 70 characters. The detail belongs in the opening paragraph.
  • heading-skip: each subsection uses the next level down (H2, then H3). If a level was picked for its look, change the CSS, not the level.
  • h2-generic: rename sections such as "Overview" or "Related" to say what they cover, in the reader's words. A "Related" block of links can be headed by its topic ("Guides on invoicing").
  • h2-repeated: two sections share a heading. Merge them, or name what makes each different.
  • few-subheadings: a long page with fewer than two H2s. Split it into sections that each answer one question, each under its own H2. Do not add headings for their own sake.
  • thin-content: if the page should rank, answer the query properly. If not (tools, legal, hubs), accept it, or add noindex, or merge it.
  • images-no-alt: describe meaningful images in the alt text; use empty alt="" for decoration.
  • generic-anchor: replace "click here" with words that say where the link goes.
  • broken-link: fix the target or remove the link.

Structured data and sharing

  • jsonld-invalid: the block does not parse. Validate the JSON; common causes are trailing commas and unescaped quotes.
  • jsonld-article-incomplete: add the missing headline, datePublished, author or image with real values matching the page.
  • schema-required-missing: add the required properties for the type from Google's documentation, filled with real values visible on the page.
  • og-missing: add og:title, og:description and an og:image at least 1200 pixels wide.

International, technical hygiene

  • hreflang-invalid: use ISO language codes with optional region (en, en-GB) or x-default.
  • hreflang-no-self: each page lists itself in its hreflang set.
  • hreflang-not-reciprocal: every alternate must list this page back.
  • viewport-missing: add <meta name="viewport" content="width=device-width, initial-scale=1">.
  • lang-missing: set lang on the <html> element.
  • mixed-content: load every resource over HTTPS.
  • slow-ttfb: measure from several locations before acting; fix with caching, a CDN or a faster origin. Audit timings are hints from one machine.

Order of work

Fix anything that stops indexing first (status, robots, noindex, canonicals), then duplicates, then on-page, then polish. One change at a time on important pages, logged in the experiments file, so you can tell what worked.

Cannibalisation and consolidation

Cannibalisation is when two or more of your pages compete for the same query and neither ranks as well as one strong page would. Search engines may swap which page they show, so rankings flicker and signals are split.

Is it really a problem?

The insights report lists queries where two pages each receive a real share of the impressions. Before acting, check:

  • Same intent? Two pages ranking for one query is fine if they serve different intents (a guide and a service page for "crm setup"). It is a problem when both try to be the same answer.
  • How much is at stake? Ignore tiny queries. Focus on queries with meaningful impressions.
  • Is one page clearly the better fit? Look at which page the live results prefer and which one you want to rank.

Choose a winner

Pick the page that best matches the intent, has the strongest links and history, and is the one you want visitors to land on.

Resolve it (in order of how often it is right)

  1. Merge: move the best content from the weaker page into the winner, then 301-redirect the weaker URL to it. Update internal links.
  2. Differentiate: if both pages deserve to exist, refocus each on a distinct intent and keyword, and adjust titles, headings and body so they no longer overlap.
  3. Canonicalise: if the pages are near-duplicates that must both stay live, point the canonical at the winner.
  4. Re-link: make internal links to that topic point at the winner with consistent anchor text; remove links to the loser from contexts about the main topic.

What not to do

  • Do not delete the weaker page without a redirect.
  • Do not noindex a page that has real links without thinking about where its value should go.
  • Do not "fix" cannibalisation by stuffing the winner with the loser's text; merge what is genuinely useful.

Afterwards

Log it as an experiment. Expect a settling period of weeks. Judge by the winner's clicks and position for the query, not by the loser's.

Competitor analysis

Looking at who ranks above you to learn what the searcher needs and what your page lacks, not to copy it. Guidance, not search-engine rules.

Who your competitors are

Your search competitors are whoever ranks for your target queries, which is often not the businesses you compete with commercially (publishers, directories, forums, marketplaces). List the top results for each query; note the page type each one is.

What to learn from one result page

  1. Intent and page type: guide, product, category, tool, comparison, local result? If your page is a different type from everything on page one, the page type is likely wrong, not the wording.
  2. What the best pages answer: the questions and subtopics they cover that yours does not; their order and depth.
  3. Evidence and experience: original data, real examples, named authors, sources, images made for the page.
  4. Format: headings, lists, tables, video, tools, calculators. Which format answers the question fastest?
  5. Freshness: dates and how recently they were updated.
  6. Search features: snippets, People Also Ask, local pack, AI answer, video, images. Which sources are cited?
  7. Titles and descriptions: what angle they promise.

Gaps, not copies

A gap is something searchers need that no top result gives well. Fill it with your own facts, experience and sources. Do not rewrite competitors' pages in other words, copy their structure line by line, or claim what you cannot support. That produces thin duplicates and risks spam policy issues.

Authority and links

Look at who links to the top pages (the kinds of sites, not a list to copy) to understand what earns links in this field: data, tools, original research, local relationships.

Choosing battles

Rank your chances by how far you are from page one, how strong the incumbents are, how well your site covers the topic and how valuable the query is. Queries just off page one with a clear content gap are the best first targets.

Keep it honest

Use public information only. Do not scrape private data, impersonate customers or use competitors' trademarks to mislead. Record the date: results change.

Output

A short table per query: who ranks, page type, what they do better, the gap you can fill with real material, effort, and expected effect with a confidence.

Content briefs and drafting

A page is worth publishing when it answers one query better than what is already there. This note covers the brief that sets that up and the drafting standard that follows it.

The brief (write this before the page)

  • Primary query and intent: one query, one intent (learn, compare, buy, do, navigate).
  • Reader: who is searching, what they already know, what they need to leave with.
  • Page type: guide, comparison, use case, glossary entry, service page, tool. Match what the results page rewards.
  • The answer in two sentences: if you cannot write it, you are not ready to draft.
  • Must-answer questions: from People Also Ask, Search Console queries and customer language.
  • Evidence available: facts, data, examples, first-hand experience the site really has, each with its source. Mark gaps as gaps.
  • Links: which existing pages to link to and from, with the anchor text that fits naturally.
  • Out of scope: what this page deliberately does not cover (and which page does).

Structure that works for readers and for answer engines

  1. H1 that states the topic plainly, close to how people phrase the query.
  2. Direct answer first: two or three sentences that answer the main question on their own. A reader who stops here still got value, and the passage can be quoted accurately.
  3. Sections in the order of the reader's follow-up questions. Each H2 covers one idea; phrase it as the question where that reads naturally.
  4. Make it extractable: short paragraphs, a list for steps or options, a table when comparing, definitions stated in one sentence.
  5. Say when it does not apply. Honest limits ("this is a poor fit if...") build trust and answer a real question.
  6. Sources: link primary sources for every claim a reader could doubt. Describe them in your own words.
  7. Related pages and a clear next step that fits the page's purpose.
  8. Dates: a true published date and, if you update it, a true modified date.

Drafting rules

  • Write for one reader at a time, in plain words. Cut filler, throat-clearing and repeated points.
  • Never invent a number, price, percentage, timeline, client, quote, review, award or case study. If you do not have it, leave it out or mark it as needed. A gap is better than a fabrication.
  • Prefer concrete over general: a real example, a specific step, a named tool, a number with its source.
  • Do not copy source text. Do not paraphrase a single source closely enough to be a rewrite of it.
  • Match the site's voice and the format of neighbouring pages exactly (fields, ids, markup, front matter).
  • Title about 50 to 60 characters with the topic first; description about 120 to 155 characters that says what the reader gets. Search engines may rewrite both.
  • Mark new pages as queued so nothing goes live until it is reviewed and scheduled.

Done means

The page answers the brief, every claim is supported or removed, it matches the site's format, it links to and from related pages, and a reviewer could check each statement against a source.

Content quality, E-E-A-T and spam policies

Search engines aim to surface helpful, reliable, people-first content. Google's published guidance on this is the benchmark; read it directly and treat this note as a summary.

What "helpful" looks like

  • It answers the real question, completely, with the answer easy to find.
  • It shows first-hand experience where relevant: real examples, what you did and saw, original material, not a rewrite of the top results.
  • It is accurate, current and honest about uncertainty and limits.
  • It is written for readers, not to catch keywords.

E-E-A-T

Experience, Expertise, Authoritativeness and Trustworthiness are qualities Google's quality raters look for; they are not a single ranking score. Trust matters most. Practical signals you control:

  • Say who wrote it and why they are qualified; link to a real author or company page.
  • Show real information about the business: legal name, address, contact route, how it operates.
  • Cite primary sources (regulators, standards, studies) and link them. Never invent statistics, quotes, clients, awards or reviews.
  • Keep a visible last-updated date and keep it true.
  • Be extra careful on YMYL topics (health, money, legal, safety): lean on official sources, avoid advice you cannot stand behind, and say when to consult a professional.

Spam policies to stay clear of

Google's spam policies name behaviours that can lead to demotion or removal. Relevant here:

  • Scaled content abuse: producing many pages mainly to manipulate rankings, whether by hand, automation or AI, without adding value for people. Publishing steadily after human review is different from mass-generating pages.
  • Site reputation abuse (hosting third-party content to borrow your site's ranking power) and expired domain abuse.
  • Link schemes: buying links, swapping them at scale, automated link building, hidden links.
  • Doorway pages, cloaking, sneaky redirects, keyword stuffing, hidden text.

A quality bar before publishing

  1. Does it satisfy the intent better than the pages that already rank, or at least differently and usefully?
  2. Is every factual claim true and sourced? Remove any you cannot support.
  3. Is there something here only you can offer (data, experience, process, examples)?
  4. Would you be comfortable showing it to a customer and to the author's expert peers?
  5. Is it linked into the site structure and free of duplication with another page?

If the honest answer to any of these is no, improve it or do not publish it.

Recipe: privacy-safe conversion tracking in GA4

Use this when the digest or the conversions job shows that GA4 receives page views but no conversions, or when you want to know which pages bring leads and not just visits. It is a pattern that runs in production (a small tracking module and a click tracker), made framework-neutral. It assumes analytics loads only after consent (see the consent banner recipe): every call below does nothing until the GA4 tag is present.

Rules

  1. Never send personal data. No names, emails, phone numbers, company names, free text the visitor typed, or URLs with personal query strings. GA4's terms forbid it, and you do not need it to measure conversions. Send categories you chose ("contact", "book"), never values the visitor entered.
  2. Use few, stable event names. Google recommends generate_lead for a lead; use it rather than inventing one. Keep your own names short, lower case, with underscores.
  3. One event per real outcome. Send generate_lead when the lead is saved (after the form succeeds), not when the button is clicked. A click is cta_click, a separate and weaker signal.
  4. Mark the outcomes as key events in GA4. Until an event is marked as a key event, GA4 counts it but does not report it as a conversion. Do this in the GA4 admin under Events or Key events (the menu has moved between interface versions); events appear there after they are first received.

Suggested events

EventWhenParameters (categories only)
generate_leada lead form was savedlead_source: contact, book, quote, the tool's name
tool_completea visitor finished a calculator, checklist or quiztool: the tool's name
view_calendarthe booking calendar was shown after a formnone
cta_clicka click on a link to a conversion pagecta_target: the path, cta_location: the page section

Mark generate_lead as a key event. Mark tool_complete too if finishing the tool is a goal in itself.

The helper (any framework)

// track.js: send a GA4 event if the tag is loaded (after consent). Never send personal data.
export function track(event, params = {}) {
  try {
    if (typeof window === "undefined" || typeof window.gtag !== "function") return;
    const clean = {};
    for (const [k, v] of Object.entries(params)) {
      if (v === undefined || v === "") continue;
      clean[k] = typeof v === "string" ? v.slice(0, 100) : v;
    }
    window.gtag("event", event, clean);
  } catch (e) {
    // analytics must never break the page
  }
}

After a form saves, call track("generate_lead", { lead_source: "contact" }). After a tool shows its result, call track("tool_complete", { tool: "roi_calculator" }).

Counting call-to-action clicks without editing every button

One listener on the document catches clicks on links to your conversion pages. Set the list to your own pages.

// cta-tracker.js: counts clicks on links that lead to a conversion page.
import { track } from "./track.js";
const CTA_PAGES = new Set(["/contact", "/book", "/quote"]);
document.addEventListener("click", (e) => {
  const a = e.target instanceof Element ? e.target.closest("a[href]") : null;
  if (!a) return;
  let url;
  try { url = new URL(a.getAttribute("href"), window.location.href); } catch { return; }
  if (url.origin !== window.location.origin) return;
  const path = url.pathname.replace(/\/$/, "") || "/";
  if (!CTA_PAGES.has(path)) return;
  const section = a.closest("[data-cta-location]")?.getAttribute("data-cta-location") || "page";
  track("cta_click", { cta_target: path, cta_location: section });
}, { capture: true });

In React, import both files once from your app entry. In Astro, add <script>import "../scripts/cta-tracker.js";</script> to the base layout (Astro bundles it). On a static site, load them as modules: <script type="module" src="/cta-tracker.js"></script>.

Check it worked

  1. With consent given, open GA4 Realtime (or DebugView with the Google Analytics Debugger) and submit a test lead. generate_lead should appear with lead_source and nothing personal.
  2. Run seo-autopilot run conversions (it needs ga4PropertyId and Viewer access for the service account). It lists the events GA4 received in the last 28 days, which ones are marked as key events, and which of the suggested events are missing or not marked.
  3. Remove test submissions from your lead list, and do not count them in a report.
Ecommerce SEO

For sites that sell products. Guidance, not search-engine rules; check the search engine's and merchant programmes' own documentation for current requirements.

Page types and intent

  • Category pages target broad commercial queries ("running shoes"). They need a clear heading, a short helpful intro, working filters and real links to products and subcategories.
  • Product pages target specific products and variants. They need a unique, useful description, specifications, honest price and availability, images, shipping and returns, and reviews if genuine.
  • Guides and comparisons target research queries and feed the product and category pages with internal links.

Product pages

  • Write descriptions for people: what it is, who it suits, sizes and materials, how it differs from alternatives. Do not paste the manufacturer's text unchanged across many sites.
  • One canonical URL per product. Variants (colour, size) either share one page with selectors or have their own pages when people search for them separately, with a canonical strategy that is consistent.
  • Structured data: Product with name, image, description, brand, offers (price, currency, availability) and review ratings only when real and visible. Prices and availability in the markup must match the page.
  • Out of stock: keep the page if the product will return; show alternatives. For discontinued products, redirect to the closest replacement or the category, or return 404/410 if nothing fits.

Faceted navigation and parameters

Filters can create thousands of near-duplicate URLs. Decide which combinations have real search demand (for example colour plus type) and make those indexable pages with their own titles; keep the rest out of the index (canonical to the clean category, noindex, or not crawlable). Keep internal links to indexable versions only. Sort and session parameters should never be indexable.

Internal linking and structure

Shallow structure: home to category to product within a few clicks. Breadcrumbs with BreadcrumbList. Link related products, accessories and guides. Avoid orphan products reachable only via search or filters.

Reviews and trust

Genuine reviews are a ranking and conversion asset; fake or incentivised-without-disclosure reviews are against policy. Show delivery, returns and contact details clearly. Secure checkout, clear policies and real business details support trust.

Merchant data

Product feeds and merchant programmes read the same facts: keep price, availability, identifiers and images in the feed identical to the page.

Speed and media

Large product images are the usual speed problem: correct sizes, modern formats, dimensions set, lazy-load below the fold, a priority hint on the main image. See media-and-image-seo.md.

Measure

Revenue and orders from organic search, not clicks alone; category and product page impressions in Search Console; crawl and index coverage of product URLs.

Editorial review checklist

Used by the reviewer agent and by humans. Each item is either blocking (do not merge) or non-blocking (note it, merge is fine). Review the diff as an editor, not as the author.

Blocking

  1. Unsupported specifics. Any number, price, percentage, timeline, client, quote, review, award, ranking claim or "customers say" statement that is not already in the site's own verified content and has no real linked source.
  2. Wrong files. Anything changed outside the content folders: workflows, build config, secrets, scripts, other pages the task did not name.
  3. Broken or made-up links. Source links that look guessed, point at the wrong thing or do not exist; internal links to routes that are not in the site.
  4. Format breakage. Fields, ids or markup that differ from neighbouring pages so the page would not build or render.
  5. Wrong promise. The title or opening promises something the page does not deliver, or the page answers a different question than the brief.
  6. Duplicated or competing target. The primary query is already targeted by another page (see the cannibalisation playbook).
  7. Copied text. Passages lifted from a source or another page.
  8. Not marked queued when the task was a new page.

Non-blocking (suggest, do not hold)

  • The direct answer could be shorter or sit earlier.
  • A heading could match the question phrasing better.
  • A list or table would make a section easier to scan.
  • A claim is true but would be stronger with a source.
  • Title or description length, or a clearer next step.
  • Missing internal link opportunities.
  • Tone drift from neighbouring pages.

How to report

List each blocking problem with the file, the exact text and what would fix it. List non-blocking notes separately and briefly. State what you checked, so the owner knows what a "pass" covers. A pass means "no blocking problem found in what I checked", never "guaranteed correct".

Entity, brand and reputation

Search engines and AI systems increasingly reason about entities: who or what a business is, what it does, where it operates and whether it can be trusted. A clear, consistent, verifiable entity helps ranking, rich results, AI answers and branded search. Guidance, not search-engine rules.

Say who you are, once, the same way everywhere

Write one plain description of the business (what it does, for whom, where) and reuse it on the home page, About page, structured data and public profiles. Use the same legal and trading name, address and contact details everywhere. Differences make you look like several different things.

On the site

  • A real About page: who runs the business, history that can be checked, how to contact you, who writes the content and why they can be trusted.
  • Author pages for people who write; link authors to their real professional profiles.
  • Organization (or Person, or LocalBusiness) structured data on the home page with name, URL, logo, contact details and sameAs links to real profiles. sameAs lists only profiles you control and that describe you.
  • Clear policies: privacy, terms, returns, complaints, and any required regulatory information (company number, registration, licence) where it applies.

Off the site

  • Consistent, accurate profiles on the platforms your customers use (business profile, professional networks, industry directories, social accounts you actually maintain).
  • Mentions and coverage from relevant independent sources: trade bodies, press, partners, customers who agree to be named. Earn them (see link-building-and-digital-pr.md).
  • A reference page such as an official registry entry, if one exists for your type of business.

Reputation

  • Reviews: ask real customers, reply to all of them politely, never write, buy or gate them.
  • Search your brand name regularly. Note what appears, what is wrong or out of date, and what you control. Fix what you can; for false or defamatory material use the platform's own process.
  • Respond to criticism calmly and factually; fix real problems.

Branded search

Branded queries (your name, name plus product) show whether people know you. Track them separately from non-branded queries in Search Console. Growth in branded search is a sign of real awareness; do not mix it into the success of non-branded content.

Knowledge panels and AI answers

You cannot request one. You can make it easy: consistent facts, structured data, reputable mentions, and a registry or encyclopaedia-style source if you genuinely qualify. If an AI answer or panel is wrong, correct the sources it relies on.

Things to avoid

Fake authors or credentials, invented awards or press, stuffed sameAs lists, buying reviews or mentions, and describing the business differently on each page.

Indexing and crawl diagnosis

Use this when pages are missing from the search results, or Search Console says "Discovered, currently not indexed", "Crawled, currently not indexed" or similar. Guidance, not search-engine rules; Search Console's own explanations are the authority.

First, find out what is true

For each page, answer in order:

  1. Does it return 200 for a normal request, and is the content in the HTML a crawler receives (not only built by JavaScript after load)?
  2. Is it blocked: robots.txt, a noindex meta tag or X-Robots-Tag header, or a login wall?
  3. Does its canonical point to itself? A canonical to another URL tells search engines to index that one instead.
  4. Is it in the sitemap, and does the sitemap list only canonical 200 URLs?
  5. Is it linked from other pages (not only the sitemap)? Pages with no internal links are "orphans".
  6. What does the URL Inspection tool say: last crawl date, user-declared and Google-selected canonical, and the rendered HTML.

What the common statuses usually mean

  • Discovered, currently not indexed: the URL is known but has not been crawled. Common on new or low-authority sites. Improve internal links, make sure the site is fast and not erroring, and be patient. Requesting indexing helps a little, in small numbers.
  • Crawled, currently not indexed: it was fetched and judged not worth indexing yet. Usually a quality or duplication signal: thin content, near-duplicates, little that is not already available elsewhere. Improve the page or consolidate it; resubmitting unchanged pages rarely works.
  • Duplicate without user-selected canonical / Google chose different canonical: the page is treated as a copy. Make the preferred version obvious with canonicals, redirects and internal links, or merge the pages.
  • Alternate page with proper canonical tag: working as intended.
  • Soft 404: the page returns 200 but looks like an error or empty. Return a real 404 or 410, or fill the page.
  • Blocked by robots.txt / excluded by noindex: check it is deliberate.
  • Page with redirect: normal for old URLs; make sure the sitemap and links point to the final URL.

What helps indexing

  • Clear internal links from relevant, already-indexed pages, with descriptive anchors.
  • A clean sitemap with accurate lastmod dates (only change them when the page changed).
  • Fast, stable responses; no long redirect chains.
  • Content that adds something the rest of the web does not.
  • IndexNow notifies some search engines about changes; Google does not use it. For Google, use the sitemap, internal links and, sparingly, the URL Inspection tool's "Request indexing" (a limited daily quota; do not spam it).
  • Fewer, better pages. A site with hundreds of near-identical pages makes all of them look low value.

How long to wait

New sites can take weeks to be crawled in full. Judge by pattern: if the same kinds of pages are never indexed after several weeks and several fixes, it is a quality or structure problem, not a delay.

Reporting

For each unindexed page: URL, status in Search Console, what was verified, the most likely cause, the fix, and who does it. Group pages by cause so one fix covers many.

Things to avoid

  • Requesting indexing for hundreds of URLs, or for pages that are blocked or duplicate.
  • Using the removals tool to "reset" pages.
  • Blaming the search engine before checking the page's own signals.
International and multilingual SEO

For sites that serve more than one language or country. Guidance, not search-engine rules; Google's documentation on localised versions is the authority.

First decide whether you need separate versions

Separate versions help when the language differs, or when the offer, price, currency, law or shipping differs by country. A translated copy of the same page for the same market adds little. If you serve a market with one version, do not create regional clones.

URL structure

Country-code domains (strongest country signal, most work), subdirectories (/fr/, /uk/; simplest to maintain and pool authority), or subdomains. Pick one and keep it consistent. Do not use cookies, IP-based redirects or Accept-Language alone to switch the version crawlers see; give each version its own URL.

hreflang

Annotations that tell search engines which version suits which user. Rules that matter:

  • Each version lists itself and all alternates (return links must exist both ways).
  • Codes are language (en, fr) optionally with region (en-GB, fr-CA). Region alone is not valid; the language comes first.
  • Add x-default for the fallback or language picker page.
  • Use full absolute URLs, and the same URLs as the canonicals and sitemap.
  • Every alternate must be a live, indexable 200 page. Annotations pointing at redirects or noindex pages are ignored.
  • Implement in one place (HTML head, HTTP headers or the sitemap), not several that can disagree.

Canonicals

Each language version canonicalises to itself, not to the primary-language page. Canonicalising translations to the original tells search engines to drop them.

Content quality

Translate with a real human check for the audience, not literally: terminology, units, currency, dates, legal wording and examples differ. Machine translation published untouched at scale is a quality risk. Translate the title, description, headings, alt text, structured data and URLs, not only the body.

Targeting and measurement

Add inLanguage to structured data, set the page lang attribute, and set up separate Search Console properties or filters per version. Judge each market on its own queries; rankings and click-through differ by country.

Common faults

Missing return links, wrong codes (en-UK), hreflang pointing to redirects, a language picker that uses JavaScript only, automatic redirects by location, duplicate content between en-US and en-GB without any regional difference, mixed-language pages.

Keyword research and clustering

A method, not a tool. The goal is a short list of topics the site can credibly win, each with a clear intent, a reason it matters to the business and evidence that people search for it.

Sources, best first

  1. Your own Search Console data. Queries you already get impressions for are proven demand. Positions 4 to 20 are the cheapest wins (the audit's striking distance list). Queries with impressions and no dedicated page are content gaps.
  2. The live results page. Search the query yourself. What page types rank (guides, product pages, comparisons, tools, forums)? That is the intent Google has chosen to serve, whatever you would like it to be.
  3. Related searches and "People also ask". Good for sub-questions and wording. They are suggestions, not volumes.
  4. Customer language. Sales calls, support tickets, reviews. Real phrasing beats any tool, and it is evidence only you have.
  5. Keyword tools. Volumes are modelled estimates and differ between tools by a wide margin. Use them to compare topics with each other, never as exact numbers. When no tool data is available, say "no volume data" instead of guessing a figure.

Judging a topic

Score each candidate on four questions, in this order:

  • Intent fit: can our page be the right kind of result for this query? If the results are all comparison tables and you would write an essay, stop.
  • Business fit: would someone with this need plausibly become a customer, or at least trust us? Traffic that can never convert is a distraction.
  • Right to win: do we have real expertise, original material or first-hand experience here? If the honest answer is "we would rewrite the top three results", skip it.
  • Competition: who ranks? A page-one full of large brands with deep sites is unrealistic for a young site. Forums, small sites and thin pages ranking suggests an opening.

Clustering

Group queries that one page should answer together. Two queries belong on the same page when the live results for both show largely the same URLs. Different intents (learn vs buy vs compare) get different pages.

  • One pillar page for the broad topic, supporting pages for specific questions, each linking up to the pillar and across to siblings.
  • One primary query per page. Record it so two pages never target the same one (see the cannibalisation playbook).
  • Before proposing a page, check the site for an existing page that already covers it. Improving that page beats adding a competing one.

Output: a topic proposal

For each proposal give: the primary query, the intent, the evidence (Search Console impressions and position, or what the live results show), the page type, the suggested working title, three to six questions the page must answer, the internal pages to link to and from, and the honest risk ("we have no first-hand data here", "results dominated by large brands").

Avoid

  • Chasing volume with no business fit.
  • Proposing many near-duplicate pages for variations of one query.
  • Presenting a guessed number as search volume.
  • Topics where the only way to rank is claims you cannot support.
Local SEO

For businesses that serve people in a place: a shop, a clinic, a trade, or a firm with a regional client base. Guidance, not search-engine rules; check Google's own documentation for the current state of each point.

What local results are built from

Search engines weigh three things for local queries: relevance (does the business match the need), distance (how near is it to the searcher or the place named) and prominence (how well known and trusted it is). You can influence relevance and prominence; you cannot change distance.

Google Business Profile

  • Claim and verify it. Use the business's real name (no keyword stuffing), one primary category that matches the main service, and accurate secondary categories.
  • Keep address (or service area for businesses without a public premises), phone number, opening hours and website current. Add real photos of the premises, team and work.
  • Add services and a description in plain language. Never add services you do not offer.
  • Reviews: ask real customers, reply to all of them politely, and never buy, trade for or write them. Do not "gate" requests so only happy customers are asked.

NAP consistency

Name, address and phone should read the same on the website, the profile and any directories you use. Small formatting differences are fine; different numbers, old addresses or a former trading name are not. Fix the sources you control first.

On the website

  • A real contact page with the full address, phone, opening hours and a map where there is a premises.
  • Local business structured data (see structured-data.md) that matches the visible page: name, address, phone, URL, opening hours, area served.
  • One page per genuine location or service area, with content that is actually about that place: who you serve there, real local detail, real work done there. Do not clone a page and swap the town name. That is doorway content.
  • Link the location pages from a clear hub and from the pages that matter to them.

Citations and links

Listings on reputable general and industry directories help consistency and discovery. Choose a few that real customers use, rather than hundreds of low-quality ones. Local press, chambers of commerce, suppliers, associations and sponsorships are better sources of links than directories.

Service-area and online-first businesses

If you serve customers remotely or across a country, a local profile may not apply or may not be allowed. Say honestly where you operate in the site's text and structured data (areaServed), and focus on topic pages rather than fake local ones.

Measuring

Track profile views, calls and direction requests in the profile itself, local queries in Search Console, and calls or form submissions in analytics. Judge changes over weeks, not days.

Things to avoid

  • Virtual offices, mail drops or fake addresses presented as premises.
  • Keyword-stuffed business names, fake reviews, review gating.
  • Several profiles for the same business at the same address.
Measuring and experiments

SEO changes are slow, noisy and confounded. Measuring honestly is what separates learning from guessing.

What the numbers mean

  • Impressions show demand and visibility. Position is an average across queries and devices, so it can move without any real change when new queries appear. CTR is clicks divided by impressions and depends heavily on position and snippet.
  • Search Console data lags by a couple of days and is sampled and anonymised for rare queries.
  • Always compare equal windows (28 days vs the previous 28, or the same period last year). Weekdays and seasonality matter.
  • Do not judge pages with very few impressions; the numbers are noise.

Brand vs non-brand

Brand searches show that people already know you. Growth in non-brand impressions and clicks is the real sign of search visibility improving. Track them separately.

Running an experiment

  1. Pick pages with enough impressions for a change to show (dozens per day is better than a handful).
  2. Change one thing: a title, a description, an intro, an internal-link block.
  3. Log it with the date (run experiments add <url> "what changed").
  4. Wait for the after-window to complete. The tool compares the 14 days after (starting 3 days later) with the 14 days before.
  5. Read the result as directional: there is no control group, so seasonality, news and other changes can explain a shift.
  6. Repeat on similar pages before generalising. One win on one page is a hint, not a rule.

Better evidence when you can get it

  • Split similar pages into a changed group and an unchanged control group and compare the groups, not before vs after.
  • Roll out gradually (a batch at a time) and keep the rest as a comparison.

Reporting

Say what changed, the dates, the metric, the size of the difference and the caveats. Never claim causation from a single before/after on one page, and never report a ranking guarantee.

Images, video and media SEO

Media helps people understand a page, can bring traffic from image and video results, and is the most common cause of slow pages. Guidance, not search-engine rules.

Images

  • Use real, relevant images that add something: photos of the work, product, team or place; diagrams made for the page. Stock filler adds weight, not value.
  • Alt text describes the image for someone who cannot see it, in a plain phrase, using the topic naturally when it fits. Decorative images get empty alt text (alt=""). Do not stuff keywords.
  • File names that describe the content (blue-ceramic-teapot.jpg), not IMG_0001.jpg.
  • Size and format: serve images no larger than they display, in modern formats (WebP or AVIF with a fallback if needed), compressed, with width and height set so the layout does not jump.
  • Loading: lazy-load images below the fold; do not lazy-load the main (largest) image; give it a priority hint and preload if it is a CSS background.
  • Responsive images with srcset and sizes where sizes vary a lot.
  • Indexing: images must be crawlable (real <img> or <picture> elements, not only CSS backgrounds or scripts), on pages that are indexable. An image sitemap helps when images are loaded in unusual ways.
  • Captions and surrounding text help search engines and readers understand the image. Put it near relevant text.

Video

  • Host where it makes sense: embedding a platform player is fine and simple; self-hosting needs good delivery.
  • Give the page a descriptive title, heading and a transcript or summary so the content is searchable.
  • Add VideoObject markup (name, description, thumbnail, upload date) that matches the page; a video sitemap can help discovery.
  • Do not autoplay with sound or let the video hurt speed: lazy-load the player until the visitor interacts.

Audio and documents

Provide transcripts for audio. For PDFs, make sure text is real text (not scanned images), give them clear titles and link to them from relevant pages. Prefer an HTML page for important content.

Open Graph and previews

Set an og:image of a sensible size for each page type so shared links look right; check the preview in the places people share.

Rights and accuracy

Only use media you have the right to use. Do not present images as something they are not (for example stock photos as your own team or work). Respect people's privacy and consent in photos and video.

Measure

Image and video impressions in Search Console, largest-element timing in speed reports, and the share of images with alt text and set dimensions in the audit.

Redirects, canonicals and migrations

Changing URLs is one of the easiest ways to lose search visibility, and one of the most preventable.

Redirects

  • 301 / 308 (permanent) when a page has moved for good. 302 / 307 (temporary) only when it really is temporary.
  • Redirect each old URL to its closest equivalent, one hop, not to the home page and not through a chain.
  • Keep redirects in place for a long time (a year or more is a common minimum) because links and bookmarks keep arriving.
  • Update internal links, the sitemap and canonical tags to the new URLs. Redirects are for outside links; your own links should be direct.

Canonicals

  • Tell search engines the preferred URL when the same content is reachable at several. It is a hint: keep it consistent with redirects, internal links and the sitemap.
  • A page's canonical should be a live, indexable, 200 URL. Canonicals pointing at redirects, errors or noindex pages are ignored or harmful.
  • Do not canonicalise paginated or genuinely different pages to one page unless you want the others dropped.

Migrating a site or section

  1. Inventory every URL (sitemap, analytics, Search Console, the crawl) before changing anything.
  2. Map old to new, one by one. Decide what to merge or retire deliberately.
  3. Implement redirects, new canonicals and a new sitemap, and keep the content and metadata the same unless you intend to change them. Change one big thing at a time.
  4. Test on a staging copy: every old URL should reach its mapped new URL in one hop with a 200.
  5. Launch and immediately re-check: redirects, robots.txt, noindex tags (a staging noindex left on production is a classic disaster), sitemap, Search Console for the new property.
  6. Monitor crawl errors, indexing and traffic for weeks. A temporary dip is normal; a lasting one means something is wrong.

Changing domains or protocols

Use the Change of Address tool in Search Console for a domain move, keep both properties verified, and keep the old domain redirecting for the long term.

Things people forget

  • Trailing-slash and uppercase/lowercase variants.
  • Hreflang and canonical tags that still point at old URLs.
  • Images and PDFs that were indexed.
  • Links inside emails, social profiles and directories you control: update them.
Refreshing, merging and pruning content

Sites accumulate pages. Some age, some overlap, some never earned a place. Looking after what exists often beats publishing more.

Diagnose first

When a page's impressions or clicks drop, find out why before touching it. The decay list in the insights report shows pages that lost visibility between two equal periods. Check:

  • Seasonality or news: does the same drop appear in earlier years, or did interest in the topic fall?
  • Indexing or technical change: is the page still indexed, canonical and linked? Did something change on the site around that date?
  • Competition: do the live results now show different, fresher or better pages for its main queries?
  • Intent drift: has the page type that ranks changed?

Decide

SituationAction
Good topic, outdated or shallow contentRefresh: update facts, add what competitors now cover, improve the answer, update the visible date honestly
Two pages overlapMerge: combine the best of both into one, 301 the other (see Cannibalisation)
Thin page on a topic you do wantExpand it into a proper answer, or merge it into a stronger page
Page with no traffic, no links, no purposePrune: return 404/410, or 301 to the closest relevant page if it has links. Do not mass-redirect to the home page
Page that must exist but should not rank (thank-you, internal search)Noindex and keep it crawlable

Refresh well

  • Change substance, not just the date. A date bump without real edits is misleading.
  • Keep the URL unless there is a strong reason to change it.
  • Re-check title and description against the query, and re-link from relevant pages.
  • Record it as an experiment so you can see whether it helped.

Prune carefully

  • Check each candidate for links and impressions first; pages with either may deserve a redirect rather than deletion.
  • Prune in batches you can monitor, not in one sweep.
  • Remove the pages from the sitemap and fix internal links to them.
Search intent and page types

A page ranks when it is the best answer to what the searcher actually wants. Keywords are only a clue to that want.

The four intents (a working model)

  • Informational: wants to know or learn ("how does", "what is", "checklist"). Best served by a guide, explainer, glossary entry or tool.
  • Commercial investigation: comparing before choosing ("best", "vs", "alternatives", "reviews"). Best served by comparisons, buyer's guides, honest pros and cons.
  • Transactional: ready to act ("hire", "pricing", "quote", "near me", "book"). Best served by a service or product page with clear next steps, proof and pricing guidance.
  • Navigational: looking for a specific site or page (usually a brand name). Make sure the right page exists and is easy to reach.

Many queries are mixed or unclear. The labels in the insights report are keyword heuristics, not a verdict.

How to check intent for a query

  1. Look at the live results for the query. Note the page types that rank (guides, product pages, comparisons, tools, videos) and what they have in common.
  2. Read the top few pages: what questions do they answer, in what order, and what do they leave out?
  3. Match your page type to what the results show. A product page will rarely rank against a wall of how-to guides, and the reverse.
  4. If the results are mixed, you may need separate pages for separate intents rather than one page doing both.

Building the page

  • Answer the main question in the first paragraph or two, then go deeper. Do not make the reader dig for it.
  • Cover the sub-questions that the best results cover, plus what they miss. This is what "comprehensive" should mean: useful completeness, not length.
  • One primary topic per page. If a second topic deserves its own search intent, it deserves its own page.
  • Make the next step obvious (related guide, tool, contact) without hiding the answer.

Common mismatches

  • A transactional query landing on a long guide with no way to act.
  • An informational query landing on a service page with no explanation.
  • A page trying to rank for a dozen loosely related queries and satisfying none.
SEO reporting

A report exists so a person can decide what to do next. It should be short, honest about uncertainty and tied to actions. Guidance for writing it; it does not replace measuring-and-experiments.md, which says how to judge a change.

Who is reading

An owner or marketing lead who is not a specialist. Use plain words, define a term once, and put the conclusion first.

Structure

  1. Headline (2 to 3 lines): what happened and whether it matters.
  2. Numbers: clicks, impressions, average position, indexed pages, and the conversion events that matter (leads, bookings, tool completions). Show the comparison period and say how much data there is.
  3. What changed on the site in the period (pages published, refreshed, merged, redirected, technical fixes), with dates.
  4. What we learned: which changes appear to have worked, which did not, and which are too early to judge.
  5. Next actions (at most five): each with the reason, an owner and the effort.
  6. Risks and unknowns: missing data, things that could distort the numbers.

Honest numbers

  • Name the period and the comparison period every time. Compare like with like (same length, similar weekdays; the same weeks last year if seasonal).
  • On a small site, percentage changes are mostly noise. Under roughly 1,000 impressions a month, say so, and prefer absolute numbers and direction over percentages.
  • Separate measured from modelled. Never present an estimate as a result.
  • Rankings fluctuate daily. Report averages over weeks, and queries rather than single positions.
  • Search Console data lags by a couple of days; analytics may block some visitors. Say when a number is incomplete.
  • Credit causes cautiously. "Followed the change" is not "caused by the change". Use the experiment log (experiments.md) for before/after where possible.

What to leave out

Vanity metrics with no decision attached, long tables nobody will read, and any claim that cannot be traced to a source.

Cadence

Weekly: a short note (what moved, what is next). Monthly: the fuller report with learnings. Quarterly: strategy review (what is working, what to stop).

Connecting to the business

Wherever the data allows, finish with leads, calls, bookings or sales from search, not only visits. If that data is not tracked, the first recommendation is to track it.

Working on any kind of website

The same SEO principles apply to every site; what changes is where you make the change. Run the profile job first: it detects the platform and writes site-profile.json. This playbook says what to do with each kind. Guidance, not search-engine rules; check the platform's own documentation for current menus and settings.

Two modes

  • Edit mode: the site's source is in this repository (a framework, static site generator or plain HTML). Agents may change files on a branch, one change at a time, and a person merges.
  • Advise mode: the site lives in a hosted builder or CMS. There are no files to edit, so agents produce exact instructions (what to change, where in the admin, what the new text should be) and a person applies them.

By kind of site

Hosted builders (Wix, Squarespace, Webflow, Framer, Shopify admin): titles, descriptions, headings, alt text, redirects and basic structured data are usually in settings screens. Typical limits: little control over the HTML, URL patterns fixed by the platform, structured data via app or settings only, no server redirects beyond a redirect manager. Prioritise content, titles, internal links, speed (image sizes, apps and scripts) and the sitemap the platform generates.

Content management systems (WordPress, Drupal, Ghost, Magento): most SEO work is in the editor and an SEO plugin or module. Watch for: plugin bloat hurting speed, duplicate archives, tag and category pages indexed with no value, default attachment pages, parameter URLs, caching serving stale pages, and staging sites left indexable. Keep one SEO plugin, not two.

Frameworks (Next.js, Nuxt, SvelteKit, Remix, Angular, TanStack Start): the main question is rendering. Server-rendered or prerendered pages put the content in the HTML; client-only rendering does not. Check metadata is set per route on the server, canonical and structured data are in the initial HTML, status codes are real (a missing page returns 404, not a 200 "not found" screen), and redirects are defined in the framework or host config.

Static site generators (Astro, Hugo, Jekyll, Eleventy, Docusaurus, VitePress): content is files, so agents work well here. Watch for: pagination and tag pages, generated sitemaps with wrong dates, trailing-slash settings, and redirect rules supported only by the host (_redirects, .htaccess, config file).

Single-page apps (Vite or Create React App without prerendering): the highest-impact fix is usually prerendering or server rendering the public pages, then everything else. Until then search engines may render slowly and AI crawlers often see an empty page.

Plain static HTML: easy to edit directly; check for duplicated headers and footers, relative link mistakes and a missing sitemap.

Where things live

Redirects: host config (_redirects, netlify.toml, vercel.json, .htaccess, nginx), the framework config, or the CMS redirect manager. Robots: a file at the root or generated by the framework. Sitemaps: generated by the framework or plugin; check that it lists only canonical, indexable 200 pages. Structured data: a component or template, a plugin, or a settings field.

What to do when you cannot edit

Write the recommendation so a person can act in minutes: the page, the field or screen, the current value, the exact new value, why, and how to check it worked. Never promise a change was made.

Moving between platforms

A platform change is a migration. Follow redirects-canonicals-migrations.md: inventory every URL, map each to its new equivalent, keep content and metadata the same unless you mean to change it, and monitor closely afterwards.

Structured data

Structured data (usually JSON-LD using schema.org types) tells search engines explicitly what a page is. It can make pages eligible for rich results, and it helps machines understand entities. It does not improve rankings directly and does not guarantee a rich result.

Rules

  • Mark up only what is visible on the page and true. Misleading markup can lead to a manual action.
  • Use the type that fits: Organization, WebSite, Article/BlogPosting, BreadcrumbList, Product, SoftwareApplication, LocalBusiness, Person, FAQPage (see below), and so on.
  • Keep the markup in the initial HTML, not injected later, so every crawler sees it.
  • Give entities stable @ids and link them (publisher, author, isPartOf) so they form one graph rather than disconnected fragments.
  • Validate with Google's Rich Results Test and the Schema Markup Validator. The audit reports unparsable JSON-LD and incomplete Article markup.

Types worth having on most sites

  • Organization (name, URL, logo, sameAs links to real profiles, contact details that are public) on the home page.
  • WebSite with the site name.
  • BreadcrumbList on deep pages.
  • Article / BlogPosting on editorial pages: headline, datePublished, dateModified, author, image, publisher.
  • Product / SoftwareApplication / Service on commercial pages, only with details that appear on the page.

Things that change

Google has narrowed or retired some rich results over time (for example FAQ rich results are now limited to a small set of sites, and HowTo rich results were removed). Markup can still be valid and harmless, but do not expect a visible reward. Check current Search Central documentation for what is supported before investing effort.

Common mistakes

  • JSON syntax errors (the whole block is ignored).
  • Marking up content that is not on the page, or reviews that are not real.
  • Several conflicting Organization or Article blocks on one page.
  • Missing required or recommended properties for the chosen type.
Technical SEO checklist

Technical SEO makes sure pages can be found, read and indexed. It rarely wins rankings by itself, but it can quietly stop everything else from working. The audit job checks most of this.

Crawling

  • robots.txt should not block pages you want indexed or the CSS and JavaScript needed to render them. Note that robots.txt controls crawling, not indexing: a blocked URL can still appear in results without a description, and a noindex tag on a blocked page is never seen.
  • List your sitemap in robots.txt. The sitemap should contain only canonical, indexable, 200 URLs.
  • Keep important pages within about three clicks of the home page and linked from at least a couple of related pages. Pages with no internal links (orphans) are hard to discover and look unimportant.

Indexing

  • Use noindex (meta robots or X-Robots-Tag) to keep a page out of results; allow it to be crawled so the tag is seen.
  • A canonical tag is a hint, not a command. Make it consistent with redirects, internal links and the sitemap, or it may be ignored.
  • Every indexable page should have a self-referencing canonical with the absolute, preferred URL.
  • Avoid several URLs showing the same content (parameters, trailing slashes, www vs non-www, http vs https). Redirect to one version.

Status codes and redirects

  • Deleted pages should return 404 or 410. Moved pages: a single 301 to the best equivalent. Avoid chains and loops.
  • Do not redirect many unrelated old URLs to the home page: search engines may treat that as a soft 404.
  • Fix internal links to point straight at the final URL.

Rendering

  • Search engines read the HTML your server sends first. Google renders JavaScript later and not always completely, and many other crawlers (including AI crawlers) do not run JavaScript at all. Put the main content, headings, links and metadata in the initial HTML (server-side or static rendering).
  • Test with "view source", not just the browser's inspector.

Mobile and speed

  • Google uses the mobile version of a page for indexing. Use a responsive layout and a viewport tag.
  • Core Web Vitals (loading, responsiveness, layout stability) matter at the margins and for users; measure with real-user data where you can. A single lab or server timing is only a hint.
  • HTTPS everywhere, no mixed content.

Hygiene

  • One H1 per page that matches the topic; logical heading order.
  • Descriptive alt text for meaningful images.
  • Valid structured data (see Structured data).
  • Correct lang attribute; hreflang only if you really have language or region variants, with reciprocal tags.
Titles, descriptions and click-through

When a page ranks but few people click, the snippet is the first suspect. Search results are a shop window: the title and description decide whether anyone walks in.

Titles

  • Lead with the words the searcher used, then the benefit or angle. The first words matter most because long titles are truncated.
  • Search engines truncate by pixel width, not character count. About 60 characters is a safe working target; wide letters use more room.
  • Make each title unique and specific. Identical titles make pages look interchangeable and compete with each other.
  • Put the brand name last (or leave it out on deep pages). Do not stuff keywords.
  • Search engines may rewrite your title if it is missing, misleading, or does not match the query. A rewritten title is a hint that yours is weak or off-topic.

Descriptions

  • The meta description is not a ranking factor, but it often becomes the snippet and affects clicks. Search engines may replace it with text from the page that better matches the query.
  • Write one specific, honest sentence or two (roughly 120 to 155 characters): what the page gives the reader, and why it is worth the click.
  • Use the language of the query. Include the concrete thing a reader gets (a checklist, a worked example, a comparison).
  • Never promise what the page does not deliver. Disappointed clicks do not help.

Diagnosing low click-through

  1. Compare the page's CTR with what its position normally earns on your own site (the insights report does this). A position-3 page with a position-9 click rate has a snippet problem.
  2. Check the live result. Is the title cut off? Does a competitor's snippet answer the query more directly? Is a rich result or answer box above you?
  3. Check intent: if the page does not match what searchers want, no title fixes that.

Fixing it safely

  • Change one thing at a time on pages with meaningful impressions. Log the change as an experiment and compare 14 days before and after (see Measuring and experiments).
  • Pages with very few impressions give noisy results; fix them for quality, not for measurement.
  • Do not rewrite titles across a whole site at once. If it goes wrong you will not know why.
Topical authority and internal linking

Search engines tend to trust sites that cover a subject thoroughly and organise it clearly. You build that with a deliberate structure, not a pile of unrelated posts.

The hub-and-cluster model

  • A hub (pillar) page gives the overview of a topic and links to every detailed page about it.
  • Cluster pages each answer one specific question or sub-topic in depth and link back to the hub and to closely related pages.
  • Each cluster page targets its own distinct query. If two would target the same query, merge them (see Cannibalisation).

Finding where to build

The insights report groups your queries into topics and flags topics that have impressions but no dedicated page. Those are the best new-content candidates because the demand is already proven. Check the live results first to confirm the intent and the page type that ranks.

Internal linking rules of thumb

  • Every page should be reachable within a few clicks and linked from at least two relevant pages. The audit flags orphans and deep pages.
  • Link where it helps the reader: inside the body text, in the sentence where the related idea appears.
  • Use descriptive anchor text ("small business CRM guide"), not "click here". Anchors tell users and search engines what the target is about.
  • Link to the page you want to rank for a topic, consistently. Do not point different anchors for the same topic at different pages.
  • Add links from older, well-linked pages to new pages; new pages otherwise start with no internal support.
  • Do not stuff pages with links. A few strong, relevant links beat dozens of random ones.

Using the audit

The audit's "internal link opportunities" list finds pages whose text mentions another page's main topic without linking to it. Those are the cheapest wins: add the link, using the phrase already in the sentence as the anchor.

Measuring it

After adding links to a page that was underlinked, watch its impressions and position over several weeks. Link changes are slow and indirect; do not expect overnight movement.