Turn AI Content Production into a Reviewable CMS Workflow

AI lowers drafting costs. It doesn’t explain why a page deserves attention: a model can produce ten thousand fluent pages before lunch, each wrong in ways that take a human afternoon to catch. This lesson treats content generation as the cheap part and review as the product — start with a real customer problem, constrain the model with references and content section prompts, keep every record reviewable, and measure a small batch before scaling.

The thread: customer problem, evidence and structure, generate and content review, release and learn.

Decide whose decision the content should help

In August 2023, an early content article described three experiments: an overseas hotel operator publishing model-written English content pages for search traffic, a Chinese site gaining traffic on a domestic search engine with model-written content, and a relative’s urban pest-control company publishing for local property managers. The first two lack preserved URLs, reporting scopes, and figures, so they cannot establish that any search engine guarantees acceptance of AI text. The third is more instructive because it identifies the audience, the location, the service, and the buying relationship. Specifics are what make a content case worth learning from.

For the pest-control company, first obtain its actual service area, available work, scheduling, acceptance process, and limits on promises. Then investigate what property managers ask. The content page should help readers decide whether to contact the company, rather than attract an unrelated entertainment click. This makes the targeted-traffic idea concrete: connect each topic to a real customer question and a next action. A topic without a question is a keyword. A topic with a question and a next action is a content page with a job.

The early content article partly justified the approach by claiming search engines could not reliably identify AI text — a detection gap is a temporary condition, not a strategy. Later guidance from the search engine (February 2023) says usefulness, reliability, originality, and service to people matter, with no special ranking reward for the content production method, and automation doesn’t excuse content primarily intended to manipulate rankings. Current generative-AI guidance calls for human fact-checking before content publication, including titles, descriptions, image alternative text, and structured data. “AI native” should mean designing from the start for machines to handle suitable repetitive work while retaining content review responsibility and evidence — not publishing every model output without an accountable reviewer. The model drafts. A named person answers for the facts.

Calibrate the content format with one complete example

Demonstrate content reference material plus a format using starter-template introductions. Provide a content example article, then reference links for a new template, asking for the name, link, description, and commentary. The example controls organisation. Content references constrain facts. A link becomes evidence only if the tool actually reads the page — if it cannot, supply retrieved source text instead of asking it to infer functionality from a URL. Content references reduce fabrication. They don’t guarantee error-free output. A model with three sources can still invent a fourth fact, neatly, between two true ones.

Two content prompts were compared. The first supplies three links and asks the model to identify common features, propose a title, and introduce the templates freely; the result is a short overview. The second explicitly requests a title, introduction, each content template’s name, link, explanation and commentary, and a closing synthesis. This produces content reviewable fields. The improvement comes from specifying the content fields readers need to compare, rather than merely asking for more words. Length is what you ask for when you don’t know what the reader needs.

The original demonstration used three named starter content templates, retained as historical examples: content templates and dependencies change, so the old commentary is not a current recommendation. The author asked for commentary in another person’s voice; your site should use truthful authorship and its own editorial voice rather than implying someone else’s endorsement. Add a genuine matching screenshot beneath each template heading after content generation, verifying the page, date, loading, and availability. A content detail page or a “best of” comparison are organisational choices; either needs criteria, audience, limitations, and actual testing. Where the source calls semi-structured content higher quality than plain text, the actionable benefit is readability and reviewability, not a universal ranking factor.

Read the directory experiment with its evidence limits

The content directory case comes from transcription notes of an approximately 150-minute livestream, published July 12, 2024, plus a recap of a July 12 investment event in Shenzhen. The transcript includes summaries, repeated speech, transcription errors, and contradictions. This content lesson uses preserved text and screenshots and doesn’t reconstruct an unavailable recording, codebase, or internal content admin system as established fact. A transcript is evidence of what was said, not evidence that what was said was accurate.

The product is an AI-tool directory. The domain was registered April 7, and the product launched April 30 after roughly three weeks of development, with plans for an encyclopedia of products, models, open-source projects, technology, algorithms, companies, and people — each term a public content page, discussions and community later connected by topic tags. The community was not open while content and traffic were being tested. Hundreds of thousands or millions of content pages were a vision, not the published inventory: fewer than two hundred listed products after two months, content generation logic still being tuned, no large-scale rollout.

The speaker reported roughly two hundred daily unique visitors in late May, four hundred around June 14, eight hundred around June 18–19, and nearly 1,100 on June 28, attributing one increase to a popular newly listed tool — the author’s explanation, without control for other factors. The screenshot spans May 20–June 28: 13.4K unique visitors, 15.1K visits, 33.9K pageviews, 2.25 views per visit, 68% bounce, 2-minute-6-second duration. The transcript separately claims tracking began June 20 and covers June 20–29, conflicting with the screenshot. These cannot form one precise timeline. Record the conflict rather than resolving it by picking the convenient half.

The console screenshot shows 6,129 clicks, 332K impressions, a 1.8% click-through rate, and an average position of 11.3, with an axis from early May to late June. The speaker separately reported five to six hundred daily search clicks and about one thousand total daily unique visitors. Don’t divide totals from different windows or combine a screenshot total with a spoken daily figure into a precise channel share — search clicks are not unique visitors. Selected content brand-query examples show the official site first and the directory second, or a content extension page ahead with the directory third. The speaker explicitly says these are some of the best content cases, not every listed product — best content cases, not the catalogue. A directory that ranks second for its best-known listings may rank nowhere for the other hundred and ninety.

Sitelinks in a brand result are an observation, not a brand-certification badge: the official guidance says they are automatically generated when site structure and query make them useful, and their absence alone doesn’t prove failed brand optimisation. The reported 138 referring domains, roughly 95,000 backlinks, and a domain rating of 58 are another historical snapshot; the livestream title’s “70 days to rating 62” is not the same instant. Domain rating is a third-party metric, and link count is not a count of independent sites or a content search-engine quality score.

Separate pages, sections, content, and references

A content system manages content; a popular open-source CMS, blogging systems, and other content systems are examples. The directory team built on its existing web-framework foundation, reusing login, payments, data mapping, and multilingual routing from two earlier products from the same team, wanting a workflow-centred system rather than one centred on manual admin clicks. That explains their choice. It doesn’t establish that existing content systems cannot automate, or that every content site should be rewritten. Understand the actual workflow first, then decide whether to reuse, extend, or build — workflow first, rebuild last.

Start with what readers see. A Page is the home for a term or product. It displays several Sections, such as introduction, features, pricing, and FAQ. A Section can contain one or several Content records for a summary, detailed answer, or item. Section definitions are reused by content type: products need features and pricing, while people may need education, company, statements, and social accounts. Generated content records identify the object and section through page and section identifiers. Keep the reusable definition distinct from a particular section’s content on a particular page — the definition is the mould, the content one casting.

Language records use a base identifier: an English content record has id 101 and base id 0; a Chinese content record has id 102 and base id 101. The presentation omitted creation time, update time, creator, and content status fields — which doesn’t make state unimportant. This is a conceptual model, not a production schema. Build from it; don’t copy it.

A page URL can be a product path, with a content section URL beneath it for the FAQ. The page name supplies the main heading, the page title supports title wording, the introduction appears in lists. Separate fields allow purpose-specific copy but don’t guarantee the search engine displays the submitted title unchanged. The author avoided public sequential IDs to discourage enumeration — an address preference, not access control; private content still needs authentication. The model produces Markdown, converted and stored as HTML to avoid repeated conversion. Precomputing content HTML and later generating and caching a complete page on request are different operations, not contradictory claims. A Content record may have its own URL without every content record becoming a public page.

Discover objects, then collect traceable factual material

Discovery runs through product-launch communities and other AI directories, using a crawler to extract and deduplicate candidates. The pending list holds the name, description, external link, and status. Discovery doesn’t establish product capability. Merge duplicate entry points, identify the official site, and then collect reference text — otherwise one product can create conflicting content pages and fragment tags, links, and reporting. Deduplicate before generating: every duplicate discovered after content publication is two pages to merge, two sets of links to redirect, and one confused reader.

Reference sources include the official site, official blog, About, team, company, product, Features, How It Works, and content FAQ pages, supplemented by verifiable technology reporting. Reference content can mix English and Chinese because it supplies model input and is not itself public. Reformatting retrieved material, adding line breaks, and extracting content fields are formatting tasks, not permission for the model to invent missing facts. A new product may postdate the model’s training, making external evidence especially important: the model’s knowledge has a cutoff date, the product launched last month, and the gap between those two facts is where fabrication lives.

For important claims, preserve the source URL, retrieval date, and applicable version, identifying an official statement, third-party report, or firsthand test. Hold conflicts for content review rather than combining two prices into a supposedly latest plan. These content review fields are a teaching extension; the source screenshot shows only the identifier, page identifier, and reference content. Mark missing pricing, performance, certification, or team information as unverified, or defer content publication, instead of asking the model to fill every column. An empty field is honest; a filled field with an invented price is a lie with formatting.

Automation progresses from manual to partly automated to automated: the author organised content references by hand until the content format stabilised, then wrote retrieval rules and used the model for content formatting. The admin still needed debugging; categories and tags were not fully automated. One transcript summary even misdefines “AI native” as early backlink promotion — not a usable definition. The lesson: specify inputs, outputs, and failure states, validate a few objects, and connect only stable steps. Automating an unstable step doesn’t remove the instability. It multiplies it by the number of content pages.

Give each section a content reviewable generation task

A section prompt inserts known material — reference content and page name placeholders — then states the audience, language, format, allowed scope, and exclusions. Introduction, FAQ, features, pricing, team, and tutorial content sections require different tasks. If a product starts with three content sections, generate them separately rather than requesting one long article and forcing it into pieces. Each content section can be revised, regenerated, and reviewed without replacing the entire page — small pieces, small failures. One long article, one long failure.

The original content introduction prompt asks for roughly one hundred Chinese characters, Simplified Chinese, Markdown, an objective third-party voice without “we,” concise language, limited jargon, and no inflated adjectives — identifying the audience, one or two core features, and how they solve a particular problem, mentioning technology only when supported, and avoiding stacked bullets, repetition, invented extensions, and copied content examples. These constraints are useful because they become content review questions, not because one hundred characters is a search-engine length standard.

A live failure was an overly broad Content Features prompt that included a usage tutorial. Narrow the content feature section to core capabilities, inputs and outputs, limitations, and audiences, moving click-by-click instructions to the tutorial. Generate before-and-after versions from the same evidence and check whether features are clearer and the tutorial has real steps before replacing content — more control than adding adjectives such as “high quality,” “professional,” or “SEO friendly.” To add information, use the product and take screenshots, then ask a model with image understanding to help organise steps, with a person checking every image and result. The author designed more than twenty content product sections but initially exposed only four or five: having a template doesn’t establish sufficient facts to publish it. A content section can wait — an unpublished content section costs nothing, a published section full of generic prose costs trust.

Two multilingual workflows exist. The static content lesson drafts a source and translates it. The directory keeps language-specific content prompts and generates each version from the same evidence, as shown for one image tool in English, German, and Dutch: ten languages mean ten generations, not one translated output copied repeatedly. Independent drafting may improve expression but can introduce factual divergence, so share the factual brief, protect validated local terms, and review each language. Ten generations cost ten times as much and buy ten chances to diverge — worth it only with ten reviews.

Validate tags before asking the model to select them

The directory doesn’t ask a model to invent a decorative list of tags. It first gathers candidates from relevant content high-traffic pages, keywords, and user tasks, cleans phrases such as text-to-speech, speech-to-text, and image-to-video, and builds a multilingual vocabulary. The source uses the trends tool as supporting evidence. Trends measures relative interest, not absolute volume, and doesn’t establish that every term deserves a content page. Beyond demand, the product must genuinely match the function. A tag the product can’t honour is a promise the content page breaks on arrival.

The tag table includes category name, tag URL, tag name, tag title, and tag description, separating Product Types from Features. App and Website describe form; Text to Speech describes a function. Each language needs real local wording. Supply the product introduction, key features, and reviewed tag list to the model and require selection only from that list. This uses the model for matching — a task with a closed answer set and a verifiable result. Unreviewed terms become candidates rather than immediately creating public content tag pages. A closed list, or no list at all: an open-ended request returns an open-ended list, and an open-ended list becomes a hundred empty content pages.

One product can have several tags, and one tag can connect many products. The author preferred tags over a single-category arrangement and reserved hierarchical relationships — a modelling choice, not proof that categories in every content system permit only one assignment. Text to Image can branch into Text to Logo, Headshot, Sticker, and PNG Image: hierarchy should help people find tools, not generate empty content pages for every combination. Build a stable tag set by hand, test it on a few product types, and check whether the model confuses content speech generation with transcription or treats every Website as interchangeable. Feed mismatch reasons back into definitions and content prompts, and automate extraction only when matching becomes reliable. These steps still involved people in the source; the intended state was not a validated system.

Create content pages for distinct tasks rather than copies

The directory uses three content page families for distinct tasks: product or term details, choices within a functional tag, and alternatives to a product. A tag collection has its own title, description, explanation, and URL and should not merely rename the same list. The directory and Text to Image collections initially listed products, with plans for free/paid distinctions and finer functional grouping that were not yet complete.

Alternative content pages discover candidates through shared features: a homework-help product may carry question-answering and chatbot functions, so explain which function each alternative can replace. The demonstration mistakenly included Website as an alternative group, and the question-answering group also contains dream, divination, and blessing tools. A shared tag discovers candidates; it doesn’t establish interchangeability. Verify inputs, outputs, accuracy, audience, pricing, and limits before recommending options. A shared tag is an introduction, not a recommendation.

When candidates are numerous, the source proposes the newest ten or twenty, a popular subset, or finer feature tags. These are display strategies, not proof that newest means best. Explain selection criteria and the update date, exclude the original product, duplicates, and irrelevant tools, and genuinely refresh a year-dated title or remove the stale year. Changing the year alone doesn’t update the evidence. Within a product, FAQ, Pricing, and Features can also serve distinct needs. First verify distinct tasks rather than splitting content pages simply because a tool lists synonyms. One inconsistent narration in the source acknowledges a better competing page; it cannot establish that separating content sections necessarily beats competitors. Avoid repeating full sections on both the content product page and section pages: useful summaries for judgement and navigation on the main page, full evidence, steps, or answers on content detail pages, linked back to the product and relevant content sections. Both should help readers, not evade an unspecified duplication threshold. Content Merge pages that answer the same task without distinct value. Multiple content pages help through clear responsibilities and links, not a rule that more pages create more ranking power.

Connect the content system to buying decisions

One speaker describes six stages: awareness, interest, trial, purchase, loyalty, and voluntary advocacy. With limited resources, serve questions close to trial and purchase first — a “best transcription software” content page may be closer to selection than a broad encyclopedia topic, but actual results and queries still matter, and “best” doesn’t automatically mean ready to pay. Explain capability, fit, limitations, and selection reasons, and ensure the destination supports a real trial. A content comparison page that recommends a product nobody can try is a dead end with good copy.

Organise hierarchy around user understanding — the source’s recipe content example moves from cakes and cookies to cheesecake and small chilled cakes. Its reassurance about depth doesn’t justify unlimited nesting: check that users and crawlers reach important content pages through relevant entry points and crawlable links, without useless intermediate steps. The source also lists interaction, dwell time, bounce rate, keyword density, and authority under search-friendliness; use engagement metrics to diagnose experience, not to claim a universal ranking score, since this material establishes no fixed density target. Useful, accurate, original content, clear titles and structure, speed, mobile usability, and relevant links beat a metric formula.

Connect content generation, rendering, caching, and release checks

The content case uses a web-framework backend on a hosting platform with a self-managed relational database; managed databases were expensive then, and costs and free tiers reflect 2024 experience, not current prices or a required stack. Start with familiar technology that serves actual traffic, and revisit cost, reliability, and maintenance as usage grows — not by designing for massive concurrency before the first content page — familiar tech, actual traffic. Scale is a problem you earn by succeeding.

Complete content pages are generated on demand and cached: a cold request reads the database, constructs a content page, and stores it for reuse, with content delivery nearby. A colleague owned the implementation; the source preserves no code, invalidation rules, or durations, so no fixed refresh interval can be inferred. An implementation should verify cold and warm requests, invalidation after evidence or prompt changes, failure retries, and rollback, so corrected prices don’t remain in stale caches — a corrected price sitting in a cache is a correction that never happened from the visitor’s point of view.

The transcript overstates that frontend rendering is unworkable because crawlers see only a shell: the search engine can execute JavaScript, and its guidance separates crawling, rendering, and indexing. Server output or prerendering reduces dependence on later scripts, but the rendered result, main content, links, status codes, and resource access still need checking. No storage choice carries its own ranking weight — inspect what is actually delivered to people and crawlers. A minimal content release record: discover and deduplicate, collect sources, verify facts, generate sections, review, content preview pages and languages, check paths, titles, links, images and rendering, publish, record the version, and observe queries and task completion. Rerunning shouldn’t create a second page for the same product; failed content sections stay pending, and evidence updates should identify affected languages, content sections, tag collections, and alternatives, so an updated content detail page doesn’t leave stale information elsewhere — one product, one page, one content version record. Duplicates are the system’s way of telling you the release check failed.

Measure cost and business results against real value

The directory used one leading language model because capability, context window, and cost relative to labour suited the experiment — not a multi-agent architecture. The source’s fixed page cost and unlimited earning potential are optimistic business language: actual costs include research, content review, translation, screenshots, storage, retries, updates, hosting, and acquisition, with no guaranteed revenue. Measure cost per accepted page, rework, impressions, clicks, and task completion on a small content batch before scaling, rather than comparing only token prices. Token prices are the smallest line; content review time, the largest, appears on no content pricing page.

The submission flow also shapes supply and revenue: the historical subscription was $9.90 per month with unlimited submissions, intermediaries could submit for clients and keep a margin, and a free route required a directory link on the submitting site, checked before waiving the fee. The reported link and rating growth doesn’t establish natural editorial endorsement when listings are tied to link incentives. Current link-spam policies address ranking-oriented service exchanges and excessive reciprocal links: review listings for content value, distinguish paid promotion from editorial selection, and qualify advertising links as sponsored or nofollow. User-submitted links separately raise user-content considerations; the two relationships are not interchangeable. The demonstration doesn’t define handling removed backlinks, dead submissions, or cancelled payments — a new content system needs explicit states and responsibility, since every submission is a lifecycle, not a row.

Monetisation ideas include company PR, advertorials, and weekly or monthly ad placements, not only selling links. Establish real audiences and useful content pages before evaluating ad income; small traffic doesn’t make monetisation impossible, but it raises the importance of fit and a credible paid path. Mirror networks, synonym rewriting, and republished encyclopedias gain no value from automation alone, and large-scale content created primarily to manipulate rankings with little benefit can violate scaled-content-abuse policies. For established terms, study the top ten results, identify tasks, evidence, and experience gaps, and produce something more specific. Many strong content home pages suggest required investment; many inner content pages reveal a page-type opportunity. Neither guarantees a new site will surpass incumbents. For naming, the author scanned three-letter .ai domains, shortlisted roughly forty-five, checked existing uses and strong sites, and chose the name. The transcript gives 17,560 combinations; 26 cubed is 17,576 — off by sixteen, a small reminder to verify even trivial claims. Availability also changes; the transferable content method is checking conflicts and actual use, not treating an old count as a current registration list.

Take one real record through a content release exercise

1. How should a content brief be written for a pest-control company? Assume the audience is property managers in one district, the topic planning shared-area pest control with minimal resident disruption. Obtain actual coverage, services, scheduling, work, and acceptance procedures. Ask the model to compare options and explain consultation preparation from that evidence, holding chemical or regulatory claims for qualified content review. The next action can be a consultation, measured by qualified inquiries and service fit rather than raw traffic alone.

2. How should a content product record be split into Page, Section, Content, and references? Assume one product has verified introduction and feature facts only. The Page stores its name, slug, title, description, and list introduction; the Section defines the introduction and feature tasks, metadata, and prompts; Content links page and section identifiers to each language’s Markdown and HTML; References store official text linked to the object, with source URLs and retrieval dates in the content review record. Without pricing evidence, defer the content pricing page rather than invent a free plan — an absent pricing page is a gap, an invented free plan a false promise.

3. How should a Features content prompt that produces a tutorial be fixed? Limit the content prompt to verified capabilities, inputs and outputs, audiences, and constraints; exclude click-by-click steps and unsupported claims. Give the tutorial its own task with real operations and screenshots. Generate old and new versions from the same material, review omissions, exaggerations, and leftover tutorial text, then replace only the accepted content feature section and check related summaries and languages.

4. Can two tools sharing a form tag be alternatives? Not from that tag alone: the form tag describes shape, not function. Compare features, then verify tasks, inputs and outputs, audiences, restrictions, and pricing. Even a shared question-answering tag doesn’t make a blessing generator equivalent to homework help. Remove mismatches, refine definitions if needed, and preserve comparison evidence.

5. How should the content system validate a pricing correction? Record the new source and date, then identify affected languages, content pricing sections, main-page summaries, tag lists, and alternative content pages. Review the diff, update content and relevant caches, and test both cold and warm requests. Inspect live HTML and rendered output, metadata, images, and links to ensure the old price is gone. Preserve a version and rollback path, then observe queries and tasks: published is not indexed, and indexed is not earning.

6. How can the team decide whether to scale this content system? Start with ten well-sourced objects and clear tasks. Measure research, model, content review, retry, and maintenance costs per accepted page, recording errors, wrong tags, failed steps, and rollbacks. After publishing, use comparable periods to inspect discovery, indexing, impressions, clicks, and qualified inquiries or trials. Expand only when quality, delivery, cost, and business value are acceptable — high domain rating or fast content generation alone doesn’t pass the gate.

Automation earns its keep when the content workflow around it is honest: real problems, traceable content references, small reviewable pieces, named reviewers, versioned releases, and a small batch measured before the big one. Build the system that makes the next hundred pages as checkable as the first ten. The model will write whatever you ask. The content workflow decides whether any of it deserves to be published.