Skip to content
nanohypenanohype

SEO baseline

Every public site the factory ships presents one canonical origin and a fixed set of discovery artifacts. The bare apex serves; www (if it exists) 301-redirects to the apex, never the reverse and never both live. Read this when building or reviewing a site's SEO surface: it fixes the canonical-host rule, the required files (robots.txt, sitemap.xml, llms.txt, og.png), the required head tags, and the one-URL-prefix Google Search Console property per site.

Nameseo-baseline
Version1
Sourcestandards/seo-baseline.json

The standard

canonical_host
rule
apex
summary

Serve at the bare apex (https://example.com/). If www exists it 301-redirects to the apex. Never redirect apex to www, and never serve both apex and www with 200 (duplicate content).

redirect
www -> apex, 301 permanent, enforced at the edge (CloudFront function or Cloudflare rule)
gsc
property_type
url-prefix
property
https://<apex>/
verification
meta-tag
summary

One Google Search Console URL-prefix property per site, at the apex origin, verified by the google-site-verification meta tag the shared SEO component emits (not a per-repo HTML file). A single Google account holds every site's property.

required_files
  • path
    /robots.txt
    description

    Allow all, agents welcome, points to the sitemap. Emitted by the shared build-time robots generator.

  • path
    /sitemap.xml
    description

    Build-generated by the shared sitemap generator from the route table — enumerates every real route, never hand-maintained.

  • path
    /llms.txt
    description

    Machine-readable site summary for agents, linked from the head via <link rel="alternate" type="text/markdown">.

  • path
    /og.png
    description
    1200x630 Open Graph share image referenced by og:image.
head_tags
  • id
    title
    required
    true
    summary
    <title>, unique per page.
  • id
    description
    required
    true
    summary
    meta description, roughly 140-160 characters.
  • id
    canonical
    required
    true
    summary

    <link rel="canonical"> absolute apex URL; must equal the served origin exactly (protocol + host).

  • id
    open-graph
    required
    true
    summary

    og:type, og:url (= canonical), og:title, og:description, og:image (+ width/height), og:site_name.

  • id
    twitter
    required
    true
    summary
    twitter:card=summary_large_image plus twitter:title, twitter:description, twitter:image.
  • id
    robots
    required
    true
    summary
    meta robots index,follow (or noindex,nofollow for non-indexable pages).
  • id
    google-site-verification
    required
    false
    summary
    GSC verification meta tag; one token per site.
  • id
    json-ld
    required
    false
    summary

    schema.org structured data (Organization / WebSite / ProfessionalService / SoftwareApplication).

rules
  • id
    apex-canonical
    summary

    Exactly one origin serves 200 and the other 301s to it, and the canonical is the bare apex. A site that serves both apex and www with 200 (duplicate content) or redirects apex to www (inverted canonical) is rejected.

    severity
    reject
  • id
    https-only
    summary
    HTTP 301-redirects to HTTPS. No plaintext origin.
    severity
    reject
  • id
    canonical-tag-matches-origin
    summary

    The rel=canonical URL equals the served apex origin exactly. A canonical pointing at www while apex serves (or vice versa) is rejected.

    severity
    reject
  • id
    generated-sitemap
    summary

    sitemap.xml is emitted from the route table at build time, not hand-written or dropped straight into a bucket. A stale or single-URL sitemap on a multi-route site is a warning.

    severity
    warn
  • id
    one-gsc-property
    summary

    One URL-prefix GSC property per site at the apex. No Domain-plus-prefix duplication and no separate www property.

    severity
    warn
  • id
    shared-implementation
    summary

    Head tags come from a shared SEO component and the files from shared build-time generators, provided as a consumed package rather than per-repo hand-rolled copies that drift.

    severity
    warn
implementation
pattern
shared-package
summary

A shared SEO layer consumed as a package, not hand-rolled per repo: a head component that emits the required tags (rendered at build time for static sites so the tags are present in the served HTML) plus build-time sitemap and robots generators.

provides
  • head-component
  • sitemap-generator
  • robots-generator
do
  • Pick the bare apex as the canonical origin for every site, no exceptions.
  • Emit head tags from the shared SEO component and pass the GSC token as one prop.
  • Generate sitemap.xml and robots.txt at build time from the route table.
  • Register one URL-prefix GSC property per site under a single Google account.
do_not
  • Redirect the apex to www (inverts the canonical).
  • Serve both apex and www with 200 (duplicate content; pick one and 301 the other).
  • Hand-maintain sitemap.xml or copy it straight into a storage bucket.
  • Carry a Google verification HTML file per repo when the meta tag does the job.
  • Mix a Domain property and a URL-prefix property for the same site.