Amir Mousavi

Checklist

SEO Architecture Checklist

Updated · By Amir Mousavi

SEO architecture is the structure that helps search engines and AI systems understand which pages exist, what each page answers, and how the pages relate to one another. A useful architecture gives every important URL a clear intent, canonical identity, and internal-link path.

Information architecture

  • Map topics to clusters: one pillar page with supporting pages. The pillar answers the broad question and the supporting pages each answer one narrow one. Build the cluster before writing, because retrofitting structure onto a pile of existing posts usually means consolidating or removing several of them.

    How to verify: List each cluster with its pillar and its supporting URLs.

    Pass when: Every indexable page belongs to one cluster, and each cluster has exactly one pillar.

  • Give every page a single, distinct search intent. Two pages targeting the same intent do not double your chances — they split the signals and let the search engine pick, often the weaker one. If you cannot state in one sentence how two pages differ for a reader, they should be one page.

    How to verify: In Search Console, break down your main queries by page.

    Pass when: No important query has two of your pages trading places for it.

  • Keep URLs readable, stable, and shallow. A URL is a durable identifier, so decide the pattern before publishing rather than migrating later; every change costs a redirect and some equity. Depth matters less than whether the path describes the content.

    How to verify: Read the URL pattern of each template.

    Pass when: URLs describe the content in words, carry no dates or IDs that will change, and the pattern is written down.

  • Avoid thin or duplicate pages competing for the same query. Thin is about whether the page answers the question, not word count. The test worth applying: does this page contain something a reader cannot get from the first three results already ranking? If not, merging it into a stronger page beats publishing it.

    How to verify: Compare each candidate page with the top three results for its query.

    Pass when: Each page offers something those results do not; the others are merged or removed.

Internal linking

  • Use descriptive, keyword-aware anchor text. The anchor tells both readers and crawlers what to expect at the other end. Vary it naturally between links to the same page — repeating one exact string everywhere reads as manipulation rather than editorial.

    How to verify: Export the internal anchor texts from a crawl.

    Pass when: No “click here” or “read more” anchors, and links to the same page use varied, descriptive wording.

  • Ensure important pages are reachable in a few clicks. Click depth from the home page is a rough proxy for how important a site considers a page. Audit for orphans regularly; they accumulate quietly whenever navigation is redesigned.

    How to verify: Check crawl depth and the orphan-page report in a crawler fed with the sitemap.

    Pass when: Important pages sit within about three clicks of the home page, and no sitemap URL is an orphan.

Templates and metadata

  • Define title and meta description patterns per template. Patterns keep a large site consistent without hand-writing every tag. Note that a meta description is not a ranking factor and is frequently rewritten in the results page — it earns clicks, it does not earn position.

    How to verify: Crawl the site and export titles and descriptions by template.

    Pass when: Each template follows its documented pattern, with no duplicates and no leftover placeholders.

  • Maintain one clear H1 per page with a logical heading order. Do not skip levels to get a font size; that is what CSS is for. Clean heading hierarchy is also what lets an assistant extract a specific passage rather than the whole page.

    How to verify: Export the H1s and heading outlines from a crawl.

    Pass when: Exactly one H1 per page, and no skipped heading levels.

  • Add structured data appropriate to each page type. Markup must describe what the page visibly shows — schema that contradicts the page risks a manual action that removes rich-result eligibility; it is not a shortcut. Match the type to the content rather than adding every type available.

    How to verify: Test one URL per template in the Rich Results Test and the Schema Markup Validator.

    Pass when: No errors, and every marked-up property is visible on the page.

Service and location pages

  • Create distinct, substantive pages — not near-duplicate stubs. Generating one page per city from a template with the name swapped is the classic doorway-page pattern, and it is explicitly against Google's guidelines. If a location page has nothing location-specific to say, it should not exist.

    How to verify: Read two location or service pages side by side with the place or service name blanked out.

    Pass when: You can still tell which page is which from its content.

  • Include local signals where relevant and accurate. Name, address, and phone should match the business profile and every other listing exactly. Inconsistent details across sources are a common and entirely avoidable cause of weak local visibility.

    How to verify: Compare the name, address, and phone number on the site with the Business Profile and the main directories.

    Pass when: They match character for character.

Technical foundations

  • Confirm canonical, hreflang, and pagination handling. The common failures are quiet ones: a canonical pointing at a URL that now redirects sends the engine a contradiction it resolves by ignoring the tag, and hreflang pairs without matching return tags are discarded entirely. For pagination, Google confirmed in 2019 that it no longer uses rel=next/prev — make every page in a series self-canonical with plain crawlable links between pages, and do not canonicalize page two to page one.

    How to verify: Inspect canonical and hreflang tags in a crawl, and run URL Inspection in Search Console on a few pages.

    Pass when: Canonicals point at 200 pages, hreflang pairs are reciprocal, and Google’s selected canonical matches yours.

  • Decide which faceted and parameter URLs deserve to exist. Filters, sorts, and tracking parameters can multiply one page into thousands of crawlable variants — the most common architecture failure on sites past a certain size. Give the few facet combinations with real search demand clean, indexable URLs and canonicalize or noindex the rest, remembering that robots.txt stops crawling, not indexing — it manages crawl budget, it does not deduplicate.

    How to verify: Crawl with parameters followed and compare the number of crawled URLs with the number of pages you meant to have.

    Pass when: Only the chosen facet URLs are indexable; the rest are canonicalized or noindexed.

  • Keep the sitemap accurate and crawlable. A sitemap listing redirected, noindexed, or dead URLs teaches the engine to distrust it, and a lastmod stamped on every build rather than on real changes is ignored for the same reason. List only canonical, indexable URLs, and let lastmod change only when the content does.

    How to verify: Crawl the sitemap’s URLs and compare lastmod values with real content changes.

    Pass when: Every URL returns 200, is indexable and self-canonical, and lastmod changes only when the content does.

  • Monitor index coverage and fix orphan pages. A growing pile of “Crawled — currently not indexed” URLs is the engine passing judgment on quality, not a bug to file. Orphans deserve particular attention here because a page only the sitemap discovers carries no internal signal of importance — it gets crawled, then quietly dropped.

    How to verify: Each month, review the Page indexing report alongside the crawl’s orphan list.

    Pass when: “Crawled – currently not indexed” is stable or falling, and no orphaned sitemap URL remains.

  • Retain server logs for at least ninety days and classify requests by documented AI crawler user agents. AI assistants fetch pages without executing analytics tags, so server logs are the only record that an answer engine read the site — and ninety days is enough history to separate a trend from noise.

    How to verify: Check the log retention setting, and run one query grouped by AI crawler user agent.

    Pass when: At least ninety days of logs are kept, and the query returns request counts per crawler.

AI search and agents

Google says plainly that appearing in AI Overviews or AI Mode needs no special optimization, no extra schema, and no AI text files. So nothing below is a ranking trick. These are the structural habits that make a page easy to quote correctly for any system that lifts passages — and for the agents that increasingly fetch pages on someone’s behalf.

  • Write sections that answer their heading on their own. Answer engines quote passages, not pages. A section whose first two sentences answer its heading can be lifted intact; one that leans on “as mentioned above” cannot. Phrasing headings as the question a reader would ask makes the match explicit.

    How to verify: Read three sections of a key page in isolation, starting from each heading.

    Pass when: Each one answers its heading within its first two sentences without needing the rest of the page.

  • Name the organization and the people behind it the same way everywhere. Engines assemble an entity from many mentions. Use one name and one description, add Organization or Person markup with sameAs links to the profiles you control, and keep the same facts in the footer, the about page, and those profiles.

    How to verify: Compare the name and description on the site, in its JSON-LD, and on every profile the sameAs links point to.

    Pass when: They match, and every sameAs URL resolves to a profile you control.

  • If you offer a Markdown rendition for agents, keep it out of the index. Some agents fetch a page to read it, and a clean Markdown version — at a .md URL or on Accept: text/markdown — spares them the navigation and scripts. Nothing requires one, so treat it as a convenience: mark it noindex, advertise it as an alternate, leave it out of the sitemap, and generate it from the page so it never drifts.

    How to verify: Request a page’s .md URL, and the page itself with Accept: text/markdown, and read the response headers.

    Pass when: Both return the Markdown with X-Robots-Tag: noindex, the negotiated one also sends Vary: Accept, and neither URL is in the sitemap.

  • Check AI crawler access at every layer, not only robots.txt. A robots.txt that allows a crawler says nothing about the CDN or firewall in front of the site, which can refuse the same request. The three layers of AI crawler access explains how to check each one.

    How to verify: Compare robots.txt with the CDN or WAF bot settings, then check the security events for verified crawler requests.

    Pass when: No layer refuses a crawler that another layer allows, unless the written policy says so.

For where automation can speed up briefs, metadata, and internal links, see the related article below.

Sources

Factual claims on this page were checked against these primary sources on October 10, 2026:

Related reading