Marketing Surfaces

Family SEO Baseline

Status: not yet implemented anywhere

Checked 2 Sept 2026 across every live repo (Website, Rissbrook, Pets, Connections): none of them have a deliberate robots.txt, a maintained sitemap.xml, or real semantic (schema.org/JSON-LD) markup. What turns up in a file search is framework boilerplate — a generic robots.txt Vite ships by default in client/public/, a sitemap.xml an Astro integration writes into dist/ at build time with nobody having decided what it should contain, one Organization JSON-LD block on the Website's own homepage and nothing else anywhere. None of that is a family decision; it's what the tooling happened to leave behind. This doc exists because none of the three should be accidental, and right now all three are.

Why this is a family-wide baseline, not a per-repo nice-to-have

The same reason anything else lives in this repo rather than in each product's own docs: every one of the family's live sites should behave the same way toward search engines and the machines that read them, for the same reasons the wordmark and the footer have to match — a visitor (or a crawler) moving between pets.amoleo.com and connections.amoleo.com should find the same baseline competence at both, not a coin flip on whether this particular product remembered to think about it.

1. robots.txt — every live repo, no exceptions

• Real, committed, intentional — not the framework default. Explicitly allows crawling of public content and disallows anything that's authenticated-only or has no reason to be indexed (API routes, admin views).
• Points at the sitemap: Sitemap: https://<host>/sitemap.xml.
• Served from the actual site root (/robots.txt), not buried in a build output path that happens to work by accident.

2. sitemap.xml — every live repo, kept current

• Lists every real, public, indexable URL — not a static snapshot that goes stale the moment a new page ships. For a repo with a build step that can enumerate routes (Astro's sitemap integration, a script over the router), generate it; don't hand-maintain a list that will drift the same way everything else in this family drifts without a check behind it.
• Excludes anything robots.txt disallows — the two files should never contradict each other.
• <lastmod> set honestly where the underlying content actually has a meaningful modified date (Rissbrook's genealogy records, a Reviews entry) — omitted rather than faked where it doesn't.

3. Semantic web schemas (schema.org / JSON-LD) — heavy use, not one block

One Organization block on the Website's homepage is not "using structured data" — it's the one place in the entire family that has any. The actual target is systematic: every page type gets the schema that actually describes it, not a single generic block copied everywhere.

Family-wide, every site:

• Organization — the family itself, https://www.amoleo.com/, on the Website's own homepage (already exists; keep it, it's correct).
• WebSite (with SearchAction where the site has real internal search — Connections and Upnext both will) on each product's own home page, naming that product, not the family.

Per product, once it has content shaped for it:

• Amoleo-Rissbrook: Person on every individual's page (already has a start at people/[id].astro — extend it, don't leave it as the one page that got it), GenealogicalPersonEvent-shaped facts where the vocabulary supports them, ImageObject for portraits.
• Amoleo-Pets: Pet-adjacent schema.org doesn't have a dedicated type — use Thing with a clear additionalType, or model each pet as a lightweight CreativeWork-free custom object; this one needs real design, not a copy-paste from another product. Flagged here as genuinely open, not decided.
• Amoleo-Connections: TVSeries/Movie for each K-Drama (Registry's own Title data, once Connections reads from it), Person for each actor, matching Rissbrook's own approach to people.
• Amoleo-Editions / Amoleo-Upnext / Amoleo-Collections / Amoleo-Reviews / Amoleo-Worldbook: each will have its own natural schema.org mapping once built (CreativeWork and its subtypes cover most of this family's actual content) — design it per repo when that repo starts writing real pages, using this section as the pattern to follow, not a blocker to wait on.
• Amoleo-Accounts / Amoleo-Registry / Amoleo-Communications / Amoleo-Images / Amoleo-Recommendations: no public, indexable content of their own (see each repo's own "behind the scenes" classification, Amoleo-Family/tools/repos.json) — robots.txt should disallow them outright rather than leaving search engines to guess, and neither a sitemap nor schema markup applies.

4. Analytics and Search Console — GTM (with GA inside it), and Google Search Console

Distinct from the three above: those are about what a crawler reads on the page; this is about telling Google what the family's sites are, and measuring what visitors actually do on them once they land. Both are family-wide tools every live, public-facing repo should be enrolled in — not a per-repo decision the way each product's own schema.org mapping in §3 is.

• Google Tag Manager, with GA4 configured inside it — never GA loaded directly — is already the family's real practice, just not previously written down here; the full consent-gated implementation lives in docs/cookie-consent.md. Status per live repo, checked 3 Sept 2026: Amoleo-Website and Amoleo-Pets both load a GTM container with GA4 configured inside it, gated behind consent as UK PECR requires. Amoleo-Connections deliberately has neither — it loads no analytics and sets no cookies at all, and adding one would ask consent for nothing. Amoleo-Rissbrook doesn't have one yet. Amoleo-Accounts won't need one unless it grows analytics beyond its strictly-necessary session cookie. Going forward: any new live, public-facing repo gets a GTM container with GA4 configured inside it, consent-gated the same way — copy docs/cookie-consent.md's implementation rather than deciding this fresh per repo.
• Google Search Console — not yet registered for any property. Checked 3 Sept 2026 alongside robots.txt/sitemap.xml/schema above: nobody has verified any Amoleo host in Search Console, so nobody is watching indexing status, crawl errors, or search performance for any of the family's live sites. Once a site has a real robots.txt and sitemap.xml (§1–2), registering it in Search Console and submitting that sitemap is the next step — no reason to wait on the semantic-schema work in §3 first. Verification method is an open, per-site choice (a DNS TXT record covers the whole domain and survives a hosting change; an HTML file or meta tag is simpler but is per-subdomain) — not decided here.

What's still open

• No checker yet. Unlike wordmark/footer/screenshots/OG-image, there's no tools/check-seo.mjs and no manifest recording per-repo status — this doc is the policy, written down before the tooling exists to enforce it, same starting point every other family spec had. A real next step, not done here.
• Amoleo-Pets' schema.org mapping is explicitly undecided (see above).
• No Amoleo host is registered in Google Search Console yet — see §4. Registering the live ones (www.amoleo.com, pets.amoleo.com, connections.amoleo.com, www.rissbrook.co.uk) is a real next step, not done here.
• Amoleo-Rissbrook has no GTM/GA container yet — see §4. Whether it gets one is an editorial call (Rissbrook is a memorial/archive site, not a product with growth metrics to track) rather than an oversight to fix automatically.
• Whether a shared sitemap-generation script belongs in this repo (like family-css's build/sync scripts) or is naturally per-repo since each site's routing is different — not decided.

Generated from docs/family-seo.md + tools/repos.json (status). Edit there and re-run npm run build in docs-site-src/ — never hand-edit a page.