C&L Strategy — SEO OS

How This Site Was Built

This presentation explains the SEO/AEO/pSEO system used to build the IV One Health site.

Audience: operators and marketers (not patients). No medical or treatment advice appears in this deck.

• Traditional SEO vs system-based SEO
• What pSEO is (and is not)
• Why it works for regulated/YMYL
• What was built (as an example)
• How it compounds

What We Built In This Website

Three programmatic page systems + a clean core site

This repo implements a Next.js App Router site with a stable layout shell and three programmatic (pSEO/AEO) systems.

Each system is generated from structured data files, rendered through consistent templates, and supported by hubs for navigation and internal linking.

• Services pSEO: `/services` hub → `/services/[slug]` pages
• Conditions pSEO: `/conditions-we-treat` hub → `/conditions-we-treat/[slug]` pages
• Guides (AEO): `/guides` hub → `/guides/[slug]` answer-first pages
• Trust pages: `/policy`, `/patient-process`, `/insurance`

Local Intent Strategy (This Site)

One location anchor + many intent-specific pages

This site is intentionally anchored to a single location (Riyadh) rather than mass city swapping.

Local intent is handled by topic-specific pages that naturally include the location context, paired with clear routing to contact and process pages.

• Avoids low-trust “{city} swap” patterns
• Uses hubs to guide users to the right page type (service vs condition vs guide)
• Converts via clarity: process + insurance info + contact (no popups)

The Core Problem With Traditional SEO

Activity Without Infrastructure

Traditional SEO is often page-by-page: write one page, optimize one keyword, repeat.

System-based SEO focuses on repeatable templates + structured data + tight internal linking + QA so you can publish many high-quality pages consistently.

• Traditional: bespoke pages, slower throughput
• System-based: scalable page generation with guardrails
• Outcome: compounding surface area without compounding chaos

Our Philosophy

SEO Is Infrastructure, Not Content

Treat SEO like a layered system: a stable foundation, scalable coverage, extractable answers, and conversion UX.

Each layer strengthens the whole system — and upgrades propagate across all pages.

• Foundation: core site + technical baseline
• Coverage: programmatic pages (pSEO)
• Authority: answer-first pages (AEO)
• Conversion: clear next steps and trust UX

What Programmatic SEO (pSEO) Actually Is

Separation of Structure and Data

pSEO creates many pages from a dataset using stable templates.

The key is governance: structure + data + QA so pages are useful, consistent, and compliant.

• Template controls UX, internal linking, and schema
• Data controls coverage and specificity (without keyword stuffing)
• QA prevents thin/duplicative pages

Why Most pSEO Fails

Scaling Without Control

pSEO fails when it’s treated as a publishing hack instead of a controlled system.

The fix is structured templates, data-driven content, controlled rollout, and quality + compliance guardrails.

• Wrong: thin pages, city swaps, keyword stuffing, mass indexing, random internal links
• Right: structured templates, data-driven content, controlled rollout, intentional linking, quality + compliance

AEO: Answer Engine Optimization

Search Is No Longer Ten Blue Links

AI-driven search often surfaces one extracted answer, not a list of links.

AEO makes your pages easy to extract, trust, and cite by structuring pages around direct answers and supporting context.

• Answer-first structure (clear, conservative wording)
• Supporting sections for context and trust
• Schema consistency for page type

Governance: How We Keep Scale From Breaking Quality

Templates + schema + dev performance controls

In programmatic systems, governance is the product. This implementation includes guardrails that keep publishing fast while maintaining consistency.

Development builds cap static param generation to keep the dev server responsive; production builds still generate the full set of pages.

• Consistent layout shell and internal linking via hubs
• Schema remains consistent by page type (no route changes)
• Dev-only cap on `generateStaticParams()` to prevent local slowdowns
• Production build still prerenders all pages for stability

Why This Compounds

Infrastructure Improves Over Time

Each dataset addition creates a new high-quality page with the same governance and structure.

Template improvements upgrade every page, and internal linking gets stronger as coverage grows.

• Add 1 data record → publish 1 new page (with the same QA rules)
• Improve the template → upgrade the whole library
• Measure → iterate → cleaner conversion paths (without popups)

What Success Looks Like

A Realistic Timeline

30 days: baseline indexing and early visibility signals.

90 days: broader coverage and more qualified actions as pages mature.

180 days: durable authority and a defensible position built on consistency.

• 30 / 90 / 180 day expectations (realistic)
• Durable visibility vs short-term hacks