From a TAMITOS story to a live page: keeping the publishing chain intact

A published CMS record is only one step towards a working article. The title, description, image and language links must also reach the generated page and survive deployment. On 22 October 2026, we corrected a specific TAMITOS rendering issue: authored SEO metadata was saved in the CMS but was not being used consistently in the static output.

The correction is now in production. This is a closer look at that release and the publishing checks behind it, rather than a claim that metadata alone will make an article rank.

The problem was between authoring and rendering

An editor can write a useful description, save it successfully and still find a different description in the live HTML. Those are separate events. A CMS confirms that it has stored a field. A renderer decides which field becomes a page element.

In the TAMITOS prerenderer, the fix explicitly reads the CMS meta_title and meta_description values. A nonblank authored title now becomes the HTML document title. The authored description takes precedence over the shorter article annotation. If those fields are absent or blank, the existing fallback remains available.

The visible headline retains its own role. Changing a browser title should not quietly replace the article's H1 or rewrite its body. The structured article headline also continues to use the article title. This distinction makes editorial control useful without making the content inconsistent.

Social metadata has its own defined path too. The renderer reads social title and description overrides, with fallbacks when they are missing, and writes the corresponding Open Graph and Twitter metadata. The change also ensures a Twitter description is present when there is a usable description.

Four states that should never be confused

The practical lesson is to name the publishing stages accurately:

1. Authored: the text, image choices and metadata have been prepared.
2. Published in the CMS: the record is saved with the intended public state and language.
3. Deployed: the build has generated and delivered the site output.
4. Verified live: the intended production URL returns the expected article and its supporting assets.

These states answer different questions. A successful save cannot prove that a build fetched the record. A successful build cannot prove that every public image URL returns an image. A working staging page cannot prove that production has been updated.

This is the same distinction we discuss in prototype versus production-ready game development. Something can work at an earlier stage while still needing evidence at the stage a customer actually uses.

A deliberately different test fixture

A useful test needs to distinguish the values that could accidentally be mixed up. If the headline, SEO title and social title are identical, a renderer can choose the wrong field and still appear to pass.

Our new metadata fixture gives those fields different values. It checks the generated title, description, Open Graph fields and Twitter fields, then verifies that the visible headline, article body, canonical URL and structured article data still have the expected values. Additional cases cover missing, empty and whitespace-only metadata.

The local fixture completed 27 assertions. That number describes a bounded regression check, not a complete audit of every publishing feature. It gives the specific metadata behaviour a repeatable test instead of relying on someone remembering to inspect it after each change.

For teams introducing AI-assisted tooling, this is an ordinary but valuable place to insist on evidence. A proposed code change should show which contract it preserves and how it checks the edge cases. Our guide to reviewing AI-generated game code develops that broader review principle.

The image belongs to the article, not just the preview

An article image needs a reliable relationship with its story. The TAMITOS media helper uses an explicit mapping from article identifiers to approved local media when the CMS record has no feature or thumbnail image. Existing CMS image fields take priority, so the fallback does not indiscriminately overwrite later editorial choices.

The helper checks approved filenames and requires the local source to exist before copying it into the build output. Image dimensions come from a separate measured-size mapping. This turns a missing source into a build problem that can be noticed, rather than silently publishing an attractive card with an unavailable hero.

The 22 October release verification also checked the public images themselves. The three topic illustrations were available as WebP, and the report recorded successful responses for their 320, 640 and 960 pixel thumbnail variants. The article checks covered the expected image, dimensions and structured-data image association.

That does not establish a universal performance score. It establishes that these specific delivered assets were reachable and matched the release's expectations. Performance still needs its own measurements on representative pages and devices.

Translation pairs need actual destinations

A Slovak article and its English counterpart do not necessarily have matching slugs. Guessing the English destination by changing /sk/ to /en/ can send readers to an unrelated page or a missing route.

TAMITOS uses an explicit article translation registry. Its final pass checks slug validity and duplicates, confirms both generated files exist, and checks canonical URLs and document languages before applying the pair. It then updates alternate-language metadata and the article language links.

Illustrative example: a Slovak article about reading with grandparents might use a phrase that translates naturally into a shorter English headline. Both routes are valid. The useful connection is the verified pair of pages, not an assumption that their path segments should match.

You can inspect the current Slovak TAMITOS blog and English TAMITOS blog. The purpose of the pairing is to preserve the reader's place when changing language. It is separate from deciding whether a translation reads naturally, a subject covered in our AI game localization quality checks.

What the production checks established

After the metadata correction, the production workflow completed successfully. The final report checked all six articles in the day's three-topic bilingual batch. Each passed the expected title and description checks, article schema and author checks, sitemap inclusion, a link from the listing, a single H1 and the absence of empty body paragraphs.

The release evidence also includes canonical, language-pair and image checks. Together, these checks support a precise statement: the six intended articles and their checked metadata were present on production. They do not show a ranking improvement, a new reader acquisition rate or a conversion lift.

Google's documentation explains that title links draw on multiple page signals and that search snippets may use a meta description when appropriate. Supplying accurate metadata gives those systems useful material. It does not force a particular search presentation or guarantee a citation in an AI answer.

A release habit worth keeping

The most reusable improvement is a clear definition of done. Save the record, build from the intended source, check the rendered contract and inspect the actual production result. Keep those steps distinguishable even when the tooling makes them fast.

For QORPO Studio, this is product work around the story: protecting what an editor intended as it moves through software. Explore what QORPO builds, or read a live TAMITOS article and follow its language and image links. The publishing chain is doing its job when those transitions feel uneventful to the reader.