From 136 Auto-Translated News Posts to Original Games

This site did not start as a game lab. For a few weeks in late May and June 2026 it was an automated AI-news blog. A pipeline took Korean tech-news summaries, translated them into English and published them here, with SEO metadata attached. This note is an honest account of why that didn’t work and what replaced it. It is written for anyone considering the same kind of automation.

Sources: this project’s commit history, its local post archive, and the site-review documents written on July 30, September 5 and September 15, 2026.

Timeline of this site in 2026, from automated news posts in May and June to original games, guides and a development log
The site in 2026, from automated news posts to original games and development records.

What the pipeline did

  • It collected Korean summaries of tech stories, most of them from a community news aggregator, and translated each into English.
  • It generated a title, description, focus keyword and table of contents, and ran SEO checks before publishing through the WordPress REST API.
  • Between May 27 and June 13, 2026 it produced 136 English posts.

Technically it worked well: posts went out on time, metadata passed every plugin check, and nothing broke. That turned out to be the wrong thing to measure.

Why it was the wrong product

Each post restated someone else’s reporting, which was itself a summary of someone else’s article. A reader who found one of those posts got nothing they couldn’t get faster at the source. The automation made that emptiness efficient; it didn’t fix it. Nobody had a reason to come back, because the site had nothing of its own to offer.

The news posts were removed. Their old addresses now return “not found” rather than redirecting to unrelated pages. The site was rebuilt around things that exist only here.

What replaced it

Date (2026)Change
JuneTwo original browser games, Netherguard and Block Smash, published with project pages and build notes.
July 25Player guides based on real playthroughs and on the rules found in the game data.
July 30A site review fixed broken metadata, full-page game runtimes leaking into search results, and play pages with too little text before the game itself loaded.
September 5A content refresh added real screenshots and corrected guide details against the current builds.
September 15A repair pass fixed the stale sitemap dates, added navigation to the play pages, and removed a beginner instruction that contradicted the game.
The Diligesker Lab home page with links to play Netherguard and Block Smash
The home page today: two original games you can start without an account.

The last item deserves a detail. One page told new players to choose a character. A fresh save in Block Smash actually starts with Iron, and the other characters unlock later. Nobody had checked the page against the game. Mistakes like that are easy to make when text is produced faster than it is verified.

What did not help

  • Adding more words about the same two games. By September the play pages already carried 600–800 words of instructions each. More text on the same subject doesn’t give a reader a new reason to visit.
  • Checklists with magic numbers. “Twenty posts”, “a thousand characters per post” and “a hundred visitors a day” come up constantly in blogging advice. None of them says anything about whether a page is useful to the person reading it.
  • Treating a passing link check as a quality signal. Every URL returned 200 while the sitemap was still wrong and a guide still contradicted the game. Checks only prove what they check.
  • Repeating trust statements. The About page once described the editorial process twice. Saying “tested” doesn’t make a page more useful; showing the test does.

What seems to matter

  1. First-hand material. The strongest pages here are ones nobody else could write, such as a walkthrough of an actual board or the story of two ad bugs that cost players their rewards.
  2. Checking claims against the source. Every guide is compared with the shipped build and every development note with the repository it describes. When they disagree, the page is corrected.
  3. Saying what wasn’t proven. The sitemap note names the plugin versions it was checked against and the case it did not test. That is more useful to a reader than a claim that the fix works everywhere.
  4. Automation behind the work, not instead of it. Scripts still publish these pages and keep the sitemap accurate. What they publish is written from real project records.

The pages that exist now are ones I would want to find myself. The news posts were not.