--- title: "SEO and GEO Website Build Standard" url: https://marketingsignals.com/seo-geo-website-build-standard type: Page --- # SEO and GEO Website Build Standard A peer-reviewed SEO and GEO website build standard: crawling, indexing, structured data, content, performance and AI visibility, with launch gates and tests. Build standard ## SEO And GEO Website Build Standard 2027 A platform-agnostic standard for building websites that search engines and AI assistants can crawl, understand and cite. Peer reviewed by Jono Alderson and Mark Williams-Cook. ## Peer review This standard has been peer reviewed by [Jono Alderson](https://www.jonoalderson.com/) and [Mark Williams-Cook](https://markwilliamscook.com/). Their review comments are incorporated in version 2.2, covering content negotiation for Markdown versions of pages, image loading priorities, crawlable pagination, share image dimensions and terminology. **Version:** 2.2 **Updated:** 9 November 2026 **Audience:** Developers, technical SEOs, content teams, designers and project owners **Scope:** New websites, redesigns, CMS migrations and major template changes > **Purpose:** Build websites that are easy for search engines and AI-assisted discovery systems to access, understand and reference, while remaining fast, accessible, accurate and effective at generating enquiries or sales. This is a platform-agnostic implementation standard, not a guarantee of rankings or citations. ## How to use this standard Every project must be assessed against three levels: | Level | Meaning | Implementation rule | | --- | --- | --- | | P0: Mandatory | Essential technical SEO, quality, accessibility and launch safeguards | Must pass before launch; exceptions require written approval | | P1: Conditional | Features required when the business model, target market or website architecture calls for them | Decide applicability at discovery; deliver applicable items before launch or document an approved phase | | P2: Experimental | Emerging GEO formats and integrations with unproven or platform-specific search benefit | Implement only with a stated use case, owner, cost and measurement plan | **Ownership:** The developer owns technical implementation and automated tests; the SEO lead owns search intent, indexing rules and redirects; the content owner owns factual accuracy and editorial quality; the project owner signs off the release. Assign named individuals at project kick-off. **Small builds:** where one person, or one person working with an AI coding assistant, does the build, these roles can collapse to a single named owner who signs off each gate in Section 15. Keep the gates and the evidence; drop the hand-offs. **Definition of done:** A requirement is not complete because it exists in the CMS or works on one example page. It must work on every applicable template, survive a deployment, and have a documented test and result. ## Tier 1: Mandatory build requirements (P0) ### 1. Environments, hosts and deployment safeguards - **Production host:** Nominate one canonical HTTPS hostname (www or non-www). Redirect alternative production host/protocol variants permanently to it. Enforce HTTPS and keep certificates valid. - **Staging and preview:** Protect staging, preview and platform-generated URLs with authentication or equivalent access controls. Do not rely on robots.txt to keep confidential or preview environments out of indexes. Make sure previews are not publicly linked or included in sitemaps. - **No accidental alternative sites:** Platform hosts and obsolete environments must not serve an unrestricted duplicate production site. Where practical and safe, redirect public alternate production hosts; do not redirect private staging previews to unrelated live pages. - **Release controls:** Production indexability must be explicitly checked at launch. A production noindex, blocked crawler, incorrect canonical host or test-domain reference is a release blocker. - **Development and production parity:** Templates, SEO fields, redirects and canonical rules must be tested in a production-like environment. Feature flags must not silently override per-page SEO requirements. - **Post-deploy smoke test:** On every deployment, fetch representative live templates and check status, robots directives, canonical, title, visible primary content and navigation. **Acceptance test:** No public indexable staging URLs; the production homepage and representative content pages return the expected 200 HTML response; all required metadata points to the production host. ### 2. URL design, migrations, redirects and errors - **Stable URL conventions:** Define routes for each content type before development, including lower/upper case, hyphens, trailing slash, language prefix and category path. Avoid unnecessary URL changes. - **Migration inventory:** For rebuilds, combine old XML sitemaps, an independent old-site crawl, Search Console landing pages, analytics landing pages, backlink targets and existing redirect rules into one source URL inventory. - **URL mapping:** Map each existing valuable URL to the same URL wherever possible, or to the closest genuinely relevant replacement. Obtain SEO approval for content consolidation and changed slugs. - **Redirect system:** Maintain editor-manageable redirects as structured records, with source, target, status and notes. Exact rules take precedence over configured patterns. Validate wildcard rules to avoid accidental broad redirects. - **One-hop redirects:** Aim for a single direct 301 or 308 to the final destination; detect loops and chains. Test HTTP, HTTPS, www and slash variations. Use temporary redirects only when the change is genuinely temporary. - **Removed pages:** Return a real 404 or 410 when no relevant replacement exists. Do not redirect every missing URL to the homepage. Design a helpful 404 page that still returns a 404 status. - **Route correctness:** Pages that do not exist must not return 200 with an empty template or an error message (soft 404). Forms and route handlers must not expose arbitrary indexable URLs. - **Internal links:** Update all internal references to canonical destination URLs rather than relying on redirects. - **Sitemaps and analytics:** Update sitemap paths, navigation, breadcrumbs, canonicals, hreflang links and campaign destinations together with any URL migration. **Acceptance test:** Every legacy priority URL has a documented outcome (200, one-hop relevant redirect, or intentional 404/410); no redirect loops or critical soft 404s; no broken high-value internal links. ### 3. Crawlability, indexability and XML sitemaps - **robots.txt:** Provide a valid robots.txt on the canonical host. Block only paths that should not be crawled and for which blocking is appropriate. Do not block critical CSS, JavaScript or rendered resources. - **Crawler policy:** Establish separate access decisions for traditional search crawlers, AI search crawlers, interactive assistant fetchers and AI training crawlers. See Section 13. Do not assume all AI agents have the same purpose. - **Indexing directives:** Make index/noindex an explicit per-page field with secure defaults by content type. Use a robots meta tag or X-Robots-Tag for non-HTML resources where needed. A crawler must be allowed to fetch a URL to observe its noindex directive. - **Canonical URLs:** Every intended indexable HTML page has one absolute, valid preferred canonical, normally self-referencing. Canonical targets should return 200, be indexable and represent duplicate or substantially equivalent content. Cross-domain canonical overrides require review. - **Duplicate URL rules:** Document treatment of query parameters, campaign tracking, filtering, faceting, sorting, internal search, pagination, print variants and syndication. Choose between canonicalisation, crawling restrictions and noindex based on what the URL actually does; do not use them interchangeably. - **XML sitemaps:** Generate sitemap indexes and sitemaps automatically where needed. Include only canonical, indexable URLs that return 200. Exclude blocked, redirected, deleted and noindexed pages. lastmod must change when meaningful page content changes, not on every build. - **Discovery:** Include the sitemap URL in robots.txt, submit the relevant properties/sitemaps in Google Search Console and Bing Webmaster Tools, and keep ownership access documented. - **Internal discovery:** Important pages must be linked from other accessible, relevant HTML pages; an XML sitemap alone is not a replacement for navigation. - **IndexNow:** Where applicable, automate notifications for newly published, meaningfully updated and deleted URLs to participating search engines. Store the verification key correctly; retry failed submissions sensibly. Submission is notification, not an indexing guarantee. **Acceptance test:** Crawl the deployed site using a search-engine user agent and a normal browser. Indexable pages are reachable, self-canonicalised, included in sitemaps and free of accidental blocks. No sitemap URLs redirect, error or carry noindex. ### 4. Rendering, HTML and technical architecture - **Crawlable initial HTML:** Serve essential body copy, headings, navigation, internal links and metadata in the initial response using SSR, SSG or another reliable server-rendered approach. Client-side enhancement is fine; critical information must not require clicks, scrolling or application state to exist. - **Real links:** Use for navigation. Do not depend on JavaScript onClick, javascript: URLs or fragment-only pseudo-links for discoverability. - **Semantic structure:** Use meaningful page landmarks (header, nav, main, footer), lists, tables, buttons and form labels. Keep core content in a sensible reading order. - **Page headings:** Use one clear primary H1 as a house style, with descriptive H2/H3 headings in logical order. Titles and H1s should be aligned in meaning, not mechanically identical. - **Unique page identity:** Each indexable URL must expose its own primary content, page title, canonical and relevant structured data. Watch for client-side routers inheriting metadata from the previous page. - **Pagination:** Provide real paginated URLs and navigable links when lists span multiple pages. Avoid infinite-scroll-only discovery. Do not canonicalise every paginated page to page one unless they are genuine duplicates. - **HTTP semantics:** Content pages return 200; redirects return a true redirect response; deleted or missing content returns 404/410; genuine server failures return 5xx. - **Caching:** Cache static assets safely, invalidate changed HTML and sitemaps promptly, and use versioned asset filenames to prevent stale frontend bundles. - **Testing:** Inspect both the raw response HTML and browser-rendered DOM for every template. Confirm content equivalence for users and crawlers. - **Alternative formats:** Any alternative representation of a page (Markdown, plain text, print or AMP variants) must not compete with the HTML page. Prefer content negotiation on the same URL (see Section 12). Where a separate URL is used, serve it with an HTTP Link: ; rel="canonical" header or X-Robots-Tag: noindex, and keep it out of XML sitemaps. **Acceptance test:** Disable JavaScript and fetch source HTML on all important templates: their principal text, anchor links, title, canonical and basic context remain accessible. ### 5. Page-level metadata and social previews Provide editable or predictably generated values for each applicable page: | Element | Standard | | --- | --- | | Title | Unique, descriptive, naturally worded, aligned with search intent and appropriate branding. Roughly 50 to 60 characters can be an editorial preview target, not a hard search-engine limit. | | Meta description | Unique, useful summary with a clear reason to visit. Roughly 140 to 160 characters can be a drafting guide, not a mandatory threshold. | | Canonical | Absolute production URL, using the rules in Section 3; optional override with validation and approval. | | Robots directive | Correct for the page type; never inherited accidentally from a staging environment. | | H1 | Visible, specific primary heading; does not need to reproduce the title word for word. | | Social metadata | Open Graph title, description, image and URL; Twitter/X summary-large-image where appropriate. Use a sensible default and page-level overrides. | | Language | Correct HTML lang for the content and accurate locale fields where relevant. | | Date and authorship | Accurate published/updated dates and named authors on content where those facts genuinely matter. | - Prevent accidental duplicate titles, missing descriptions, placeholder metadata and production pages referencing staging asset URLs. - A 1200 × 675 (16:9) share image is a sensible universal default: it suits Google Discover and the main social platforms. It is a design asset, not a search ranking requirement. Social image alternative text can be supplied through supported platform tags where useful. - Allow large image previews with max-image-preview:large in the robots meta tag, so pages are eligible for large images in Google Discover. - Do not generate hundreds of near-identical titles just to insert keyword variants. **Acceptance test:** Template sampling finds the correct metadata in raw HTML. Automated reports flag missing fields and unintended duplication; exceptions are reviewed rather than blindly padded to a character count. ### 6. Structured data and entity consistency - **JSON-LD implementation:** Use supported, valid schema.org types that accurately describe the visible page. A connected @graph and stable @id values are preferred when they simplify reuse, but one graph is not compulsory. - **Single source of approved facts:** Store brand name, legal identity, site URL, logos, contact details, service areas, leadership and verified public profiles in one governed data source used by templates and schema. - **No invented attributes:** Do not add ratings, awards, pricing, credentials, author details or entity relationships that are not substantiated. Never add markup solely because a validator accepts it. - **Visible-content alignment:** Structured data claims must correspond to genuine page content and the current offer. Remove or update markup when the underlying information changes. - **Validate correctly:** Run Google Rich Results Test for Google-supported rich-result types and Schema Markup Validator for general schema correctness. Passing validation does not guarantee an enhanced search result. **Core and common conditional schema modules:** | Content | Relevant types and properties | | --- | --- | | Site identity | Organization or a suitable subtype; WebSite; stable organisation @id, official logo, verified profiles | | Site hierarchy | BreadcrumbList on appropriate non-homepage templates, matching the visible breadcrumb trail | | Editorial | Article / BlogPosting, accurate author, publisher, datePublished, dateModified, image | | Services | Service, provider, areaServed, relevant offers where truthful and useful | | People | Person on genuine author/team pages with verified biographies and profiles | | Video | VideoObject with actual upload date, thumbnail, location and duration where known | | Employment | JobPosting on active jobs, following current search-engine requirements and removing expired postings | | Ecommerce | Product, Offer, AggregateRating where permitted and accurate; variants and availability as appropriate | | Location or events | LocalBusiness, Event and relevant business-specific types when applicable | | Glossaries / ordered lists | DefinedTerm, DefinedTermSet, ItemList where they truthfully describe page content | **FAQ note:** Useful FAQs are an editorial choice; FAQ schema must not be treated as an assured Google rich result or AI citation technique. Google's FAQ rich results were discontinued in 2026. **Acceptance test:** Representative URLs from every schema-bearing template validate without errors; all substantive claims are visibly supported; references resolve to the correct brand/person/page entities. ### 7. Information architecture and internal linking - **Design for user intent:** Plan a hierarchy that distinguishes navigational, informational, comparison and transactional needs. Do not create a page solely because a keyword variant exists. - **Navigation, breadcrumbs and pagination:** Main navigation, contextual links, breadcrumbs, pagination and HTML lists expose the most important pages without JavaScript-only interaction. Pagination is a common failure: every page in a series needs a real link, not only a JavaScript "load more" button or infinite scroll. - **Topic relationships:** Service pages link to applicable sub-services, industries, supporting guides and case studies. Editorial content links to related content and relevant commercial destinations where genuinely helpful. - **Internal links as content data:** Prefer CMS relationships for links to internal pages so slug changes update destinations automatically. Provide link checks for any manual URLs. - **Anchor text:** Descriptive and natural; avoid repeated exact-match anchors where they read unnaturally. Accessible labels must make sense outside their immediate sentence. - **External citations:** Link normally to useful evidence and authoritative sources. Use rel="sponsored" for paid placements, rel="ugc" for user-generated links, and rel="nofollow" where a link should not be endorsed. Do not automatically nofollow all sources or comparison-list references. - **New tabs:** Open links in the same tab by default unless there is a clear UX reason not to. When using target="_blank", use safe rel values and communicate behaviour when helpful. - **Orphans and depth:** Automatically report indexable pages without relevant incoming internal links, including those only discoverable in sitemaps. **Acceptance test:** No important orphan pages, unintended broken links or misleading anchors. Key commercial and editorial journeys can be navigated using ordinary HTML links. ### 8. Content, GEO and evidence standards Content is built first to answer real customer questions and demonstrate why the business is credible. The same qualities support search engines and AI-assisted discovery; no particular formatting guarantees citation. - **Clear answer or proposition:** Explain what the page is about near the beginning. Commercial pages should establish the offer, audience, benefit and proof without making visitors wade through generic content. - **Original value:** Include first-hand expertise, examples, credible comparisons, unique data, transparent methodology or direct experience that cannot be reproduced from generic summaries alone. - **Entity accuracy:** Name products, people, brands, standards, platforms and places precisely where relevant. Use specific examples rather than vague claims; do **not** impose arbitrary entity-density quotas. - **Claims and evidence:** Maintain a governed claim register containing the exact approved claim, source/evidence, methodology, scope, approval owner, date checked and permitted reuse. Use consistent language when repeating important results. - **Structure for reading:** Use clear headings, concise paragraphs, bullets, comparison tables, FAQs and short takeaways when they genuinely make the page more useful. No fixed rule for FAQ count, paragraph length, first-answer position or percentage of question headings. - **FAQs:** Answer meaningful questions in natural language, with self-contained explanations and links where needed. Avoid filler FAQs added only for keywords. - **Freshness:** Show a visible reviewed/updated date where useful. Only change dateModified for meaningful updates; schedule reviews for time-sensitive pricing, product claims, legislation and platform guidance. - **Authorship and trust:** Make relevant author credentials, company identity, contact routes, editorial policies and relevant regulatory disclosures available and accurate. - **Source quality:** Prefer primary documentation and original data for factual assertions. A sources section is desirable for research-led and reference content; outbound citations should remain normal followed links unless a specific qualification applies. - **Editorial quality:** Use UK English where appropriate to the brand; preserve proper names and product terminology. Check spelling, grammar, accessibility, accuracy, duplicated sections and unsupported figures before publication. - **AI-assisted production:** Human review, factual verification and original contribution are mandatory for material produced with AI. Avoid large volumes of near-duplicate or unoriginal pages created mainly to target search traffic. #### Recommended default patterns These are starting points that have worked well on service and editorial sites, not quotas. Use them unless the page has a better reason to do something else. - **Summary block near the top:** On commercial pages, a short panel directly below the hero with three or four complete, standalone claims (each one sentence that makes sense quoted on its own), led by the strongest approved proof and followed by a clear call to action. Build it as a removable block with a site-wide off switch, so it can be tested and withdrawn without editing every page. - **Sell in the top half, answer in the bottom half:** Keep benefit-led headings, proof and the offer above the fold and in the first sections. Put informational content (how it works, accordions, FAQs) lower down, where question-style headings suit readers looking for detail. - **Answer echo:** Where a heading is a question, open the section with a sentence that restates its subject and answers it directly ("Law firm PPC campaigns are structured by case type, because..."). - **Specific names over vague references:** "Ahrefs and Semrush" rather than "SEO tools"; "the FCA" rather than "regulators". Use this as an editing habit and an audit signal, not a percentage target. - **Self-contained FAQ answers:** Each answer stands alone and links to the deeper page where it helps. - **Consistent proof:** When a case-study result is repeated (summary blocks, FAQs, schema), reuse the exact approved wording from the claim register. **Acceptance test:** Each priority template has a defined user goal, clear main answer/offer, relevant real-world proof and verified material claims. Content owners approve evidence before launch. ### 9. Images, video, performance and accessibility #### Images and video - Use descriptive filenames where practical, responsive sources (srcset/sizes), correct image dimensions and modern formats where compatible. - Write meaningful alternative text for informative images. Use empty alt="" for purely decorative images. Do not repeat adjacent captions verbatim or force keyword stuffing into alt text. - Use original imagery and charts where they add evidence. Reusing a logo or illustration is acceptable when it is the right design choice; a blanket rule against repeat images is unnecessary. - Never lazy-load the primary above-the-fold (LCP) image. Give it fetchpriority="high" and preload it (, with imagesrcset/imagesizes for responsive images). - Use fetchpriority="low" and loading="lazy" on below-the-fold images, and loading="lazy" on below-the-fold