The unpublished article still carried the error in its description

On 2 September 2026 we took a news article off kokkekunst.no for the first time. The unpublish action already existed. Using it for real showed something the tests had not checked: the article we removed for an error still carried that error in a field that readers and link previews could see.

Why the article came down

The newsroom engine published the same story twice: the jury announcement for the Norwegian championship in culinary arts (NM i kokkekunst). One version came from NKL’s announcement on 31 August. The other came from a trade-magazine article on 2 September. The engine groups articles about the same event only within a single run, so the two stories were never compared. The changelog for version 0.3.1 describes the gap, and so does the task file.

The duplicate was also the worse of the two. It called NKL “Norges Kokkemesteres Landsforening”. That is the name the organisation stopped using in 2018, and it did not appear in the source text at all. The fact gate flagged it word for word. A separate model check flagged that the source itself used two different names for the same jury member. The story went to the review queue, and someone released it from there. The changelog puts it this way: “Portene virket - de ble overprøvd.” (The gates worked; they were overruled.)

So we unpublished it.

How unpublishing works

An unpublished article does not disappear. Its URL stays, and the page becomes a tombstone: a short notice explaining why the article was removed. The engine rewrites the article’s markdown file with flags for unpublished and noindex, commits it and pushes it to the site’s repository. The kokkekunst.no site then rebuilds.

The tombstone file was built from the article’s normal frontmatter, with those flags added on top. That meant every other field came along unchanged, including lead, the standfirst.

What the tombstone leaked

A reader opening the URL saw only the tombstone. The page body was correct. But the site’s article template uses lead as the page description. The commit message points to it directly: the template passes the lead in as the description. That value becomes the meta description and the text shown when someone shares the link.

The wrong organisation name was in the lead. In the commit’s words, a story taken down because the lead contained an error “ville altså servert feilen videre til alle som delte lenka”. It would have kept serving the error to everyone who shared the link. The commit also says this is exactly what happened here: “gravsteinen gjentok navnet i beskrivelsen”. The tombstone repeated the name in the description.

The visible part of the page had been fixed. The part that search engines and share cards read had not.

How it was found

The commit message calls it the first real unpublishing, and the changelog headline for 0.3.1 is “the first unpublishing, and the two errors it revealed”. The existing test for the tombstone checked that the article body was gone. It did not check the lead.

The fix

The tombstone now replaces the lead with a fixed sentence: “Denne saken er fjernet fra kokkekunst.no.” (This article has been removed from kokkekunst.no.) The title is deliberately kept. The commit gives the reason: the URL and outside links point to it, and a reader should recognise the article they were looking for.

A regression test now renders a tombstone for a sample article. It asserts three things: the original lead text is absent, the replacement lead is present, and the title is still there. A comment above the test records the date and the reason: “Denne bet oss 2026-09-02.” (This one bit us on 2 September 2026.)

A second fix in the same commit

Fixing a published error should be the fastest path in the system, and it was not. Unpublishing was only available as a button on the article screen in the admin interface. That screen sits behind a login, so it needed a browser with an active session. The same commit added an avpubliser (unpublish) command to the engine’s command line. The commit says it follows the same code path as the button: tombstone, commit, push, audit trail. The command takes a slug and a reason, and it refuses to run without both. The reason is printed on the public tombstone, and the error message tells the operator to write it for the reader.

The command also accepts an article that has already been unpublished. A tombstone is text readers see, and if the reason is unclear or wrong, it should be possible to rewrite it without editing the database by hand.

What Claude got wrong here

The newsroom engine uses Claude to write drafts. The story that went out contained a name the source did not contain, and the fact gate caught that. This post, though, is about the tombstone that kept the lead. Henning writes no code himself, so the original tombstone code, which reused the normal frontmatter, was Claude’s. The changelog’s headline for the fix, “Gravsteinen tok ikke med seg ingressen ut”, says that the tombstone did not take the lead out with it.

The gap behind the duplicate

The task file lists the gap that let the duplicate through as a known gap. It gives three options and does not choose one:

• let the grouping step look at recent published stories, not only the current run
• compare a new story against published titles using the same similarity check deduplication already uses
• give the verification step the nearest published stories and ask whether the topic is already covered

Until then, the rule in the changelog is manual: before releasing a story from the queue, search the archive for its topic.

The rule

When an article is removed because of an error, replace every field that repeats the error, not just the one readers see on the page. On kokkekunst.no, that means the lead, because it also serves as the meta description and the share text. A regression test now checks this.