AI-Native CMS Part 2: Data, Tags and Programmatic SEO

Part 1 of this series covered the architecture: plan the site around AI from zero, one page per noun, sections per user concern, and slugs instead of numeric IDs. Part 2 goes one level deeper — where the data comes from, how the content is generated without hallucinating, how tags become pages, and how performance and keyword strategy hold it all together.

1. Automate data sourcing: the foundation everything stands on

An AI-native site dies the moment a human has to type each entry by hand. The reference implementation runs its own crawler: it scrapes Product Hunt, Hacker News, and major AI directories, dedupes the results, and keeps a watch list of pending pages — each record holding the Page Name, description, external links, and a status flag.

This pipeline is the foundation because everything downstream depends on it. Fresh entries feed the reference-content table (see below), the reference table feeds generation, and generation feeds pages. If the discovery step is manual, the whole machine slows to human speed. The crawler does not need to be fancy — it needs to run on a schedule and keep its records tidy.

2. Anti-hallucination: the reference-content table

Here is the hard problem nobody talks about: the new AI products you list every day did not exist when GPT was trained. Ask the model to write about them from memory and you get confident fiction. The fix is a reference-content table in the database — a holding pen of source material per product: the official website, tech-media coverage, the official blog, and the About, Features, FAQ, and How-It-Works pages.

These materials are never published. They exist for the model’s internal use only. Every generation step reads from the reference table first, so the output is grounded in real facts: real feature names, real pricing, real team information. Think of it as retrieval-augmented generation without the retrieval library — the crawler did the retrieval, the database stored it, and the prompt passes it in.

The practical takeaway: separate your content pipeline into two verbs — collect and generate. Collecting is crawling, scraping, and storing references. Generating is GPT formatting those references into pages. Never let the model do both jobs at once.

3. From manual to automatic: the formatting pipeline

In practice, the pipeline evolves through three stages. Stage one is fully manual: a person opens the reference pages, picks what matters, and writes the input for GPT. Stage two is semi-automated: the crawler collects the raw material, and GPT is asked to format it — restructure, clean, normalize — not to invent. Stage three is fully automated: the code does what the human did in stage one.

The key insight is the middle step. Before you write code, do the formatting by hand a few times so you know what the machine should do. Write the prompt that asks GPT to format, not to generate: “extract the feature list from this page into this JSON shape” rather than “describe this product.” Formatting prompts are reliable; creative prompts hallucinate. Once the formatting output is consistently good, automate the loop and keep the human only for spot checks.

4. Multilingual done right: generate per language, not translate

A site like this does not translate. The reference material for a product is fed to ten language-specific prompts, and each language is generated natively from the same source. That sounds expensive — and it is — but the math works: a page that costs extra to generate can bring hundreds to thousands of clicks in a language you would otherwise never reach.

The alternative, write-then-translate, produces pages that read like translations and rank like translations. Natively generated pages read as if a native writer produced them, because effectively one did. Product names stay untranslated (they are proper nouns); descriptions, feature points, and intros are written fresh in each language. As covered in Part 1, the Page table links the ten language records with a shared BaseID, so each language version knows its siblings.

5. Tag discipline: only tags with search volume

Tags are where most content sites quietly destroy themselves. The rule here is strict: a tag exists only if people actually search for it. GPT never invents tags. The workflow is reversed — humans build and clean a tag list, and GPT is only allowed to attach tags from that list to products.

The taxonomy has two groups: product type (what the thing is) and feature points (what it does). And there is a structural decision borrowed from Toolify: tags only, no categories. A product can have only one category but many tags, so tags do the real classification work. When a tag collects too many products, you either show the newest 10 to 20, show the hottest, or split into finer second-level tags — “text to image” breaks down into “text to logo”, “text to headshot”, “text to sticker”, and “text to png image”.

6. Programmatic SEO: every tag is a page

This is where tags pay rent. Each tag gets its own “t” page with its own URL, title, and description, listing every product under that tag. Same-tag products become each other’s alternatives pages, capturing queries like “Product X alternatives 2024” — one of the highest-intent search patterns in software.

Two rules keep this from becoming spam. First, only generate alternatives pages for feature tags, not for product-type tags: nobody searching “website” wants an alternatives list, but someone searching a specific feature does. Second, the Page page carries only section summaries, with details linked off to Section pages — the same information never appears twice in full, which is how you avoid duplicate-content penalties.

The broader principle: optimize cooperatively across many pages, never bet everything on one. One keyword gets its own page; the keyword family gets a structure. When a keyword has real volume and a winnable top ten, you build the page, the tag page, and the alternatives page as a unit.

7. Speed is a ranking factor: multi-level caching

AI-generated pages are expensive to build at request time. The solution is multi-level caching: the first visit pulls from the database, generates the page, and stores it in cache; later visits read the cache directly. In front of that, a Cloudflare CDN serves the page from the nearest edge. Fast pages rank better and convert better — this is not optional polish, it is infrastructure.

The same applies to the tech choices. The reference stack is Next.js front to back on Vercel with a self-hosted PostgreSQL database (managed database costs on Vercel and Supabase were too high for the scale), and no owned servers. The principle: ship with the technology you know best, carry 100 percent of early traffic on free tiers, and upgrade only when the bill is justified. Speed of shipping beats architectural elegance.

One iron rule for SEO: the HTML returned to crawlers must contain the full content. Pure client-side rendering leaves crawlers staring at an empty shell — whatever framework you use, render the content server-side or pre-render it.

8. Judging winnable keywords and monetizing after traffic

Not every keyword is worth chasing. The quick test: search the term, look at the top ten. If most results are homepages with heavy backlink profiles, move on — it is a fortress. If most are inner pages, a fully optimized site has a real shot at overtaking them. And some terms are owned outright — keywords bound to Google itself or to a brand name — those you skip entirely.

Monetization comes after traffic, and it is not link selling. The reference site’s Submit model (paid plus link-exchange submissions) was a growth engine, not a revenue line. Real revenue arrives when the traffic does: rented ad placements on a weekly or monthly basis, and PR articles for newly funded AI companies that need announcements published. Build the traffic asset first; the revenue models walk in on their own.

(Figures and case details in this article are as reported in the source material and have not been independently verified.)

Series: Overseas Website Building