Building the Real SEO™ Life Content Engine
How We Defined the Publishing Workflow That Turns Krisada.com Ideas Into Multiple Content Types for RealSEOLife.com
Three things became clear during the build.
What was measured.
Three readings from the build that turned one canonical source into a repeatable publishing workflow. The small numbers are the point.
A downstream property's job is not to republish the canonical. It is to make the idea useful in a format that fits the receiving site's purpose.
Structure is what lets a transformed idea read to a AI system as its own thing rather than as a duplicate of its source.
A workflow that depends on remembering is not a workflow. Three files moved it into the code that publishes, where it cannot be skipped.
The short version.
This case study documents the website build of the RealSEOLife.com content engine ... the workflow spec, the cross-property adaptation model, and the JSON-LD @graph system wired into every article page.
The key finding was that a downstream property does not republish canonical content.
It uses the idea as source material for whichever content types best serve its own purpose.
Explain it to me like I'm ten.
We figured out the rulebook for turning one idea from Krisada.com into the right kind of content on RealSEOLife.com, whether that's an article, a case study, or something else, instead of just copy-pasting the same thing everywhere.
What was the system?
RealSEOLife.com existed with articles, case studies, and a renderer but no documented workflow for how ideas move from their canonical source on Krisada.com into this site.
The content-engine.md file was sitting untracked in downloads/ and described Krisada.com's architecture rather than this site's.
The JSON-LD slot in head.php was wired but nothing was generating output for article pages.
The site needed a defined operating model before publishing more content.
What changed?
Started by reading the existing untracked content-engine.md and comparing it against the actual repo structure: the data/ directory, normalize_article(), the article template, and the sample schema.
Rewrote the doc to match this site's real architecture.
Verified the first article (why-seo-is-becoming-ai-to-ai-communication) was already live and rendering correctly.
Built build_article_json_ld() in functions.php to generate a schema.org @graph from normalized article data and wired it into the router's article case.
Attempted a direct article copy from Krisada.com ... identified it as wrong, removed it, and updated the content-engine.md to capture the transformation model explicitly.
What did the evidence show?
Three things became clear during the build.
First, the mechanics were already in place. The renderer, normalizer, router, and JSON-LD slot all worked.
What was missing was a documented model for what to publish and how to get it there.
Second, the adaptation model goes further than rewriting.
A Krisada.com teaching article does not become an article here.
It becomes whatever content type RealSEOLife.com needs the idea to be:
- A case study if something was built and measured
- An experiment if something is being tested
- A concept if a term needs anchoring
The content type can change entirely.
Third, the JSON-LD @graph generates cleanly from normalized article data with no per-article pre-configuration.
Every article now emits five nodes automatically:
- WebSite
- Person
- WebPage
- Article
- BreadcrumbList
Articles with an isBasedOn value in their json_ld field carry the cross-property attribution back to the Krisada.com canonical.
What can be reused?
A downstream property's job is not to republish the canonical.
Its job is to make the idea useful in a format that fits the site's purpose.
The content engine is the workflow that enforces that at publish time.
Keep Browsing the Case Library
Move from this evidence file back into the full proof system.