The status page counted another site's traffic as kokkekunst.no's

The newsroom engine behind kokkekunst.no has a status page. Part of it is a visitor panel that covers the last seven days: page views, visits, pages per visit, the most-read pages, where readers come from, and which countries they are in. Those numbers turned out to include traffic from a different website. The query behind the panel never asked which site a page view belonged to.

Claude wrote the query, so this was Claude’s mistake. Here is how it worked, how it showed up, and what changed.

How the numbers are fetched

The panel does not count anything itself. kokkekunst.no uses Cloudflare Web Analytics, which is cookie-free. The changelog gives that as the reason the site has no consent banner and keeps no counts of its own. Each time the status page loads, the newsroom engine sends one GraphQL query to Cloudflare’s API and shows the result. The rest of the page does not wait for it. If Cloudflare has not answered within eight seconds, the panel says “unavailable” and shows the error message as written.

That query has five groupings, all built on the same dataset of page loads:

• a total (page views and visits)
• the top hostnames
• the top 20 paths
• the top referring hosts
• the top countries

Each grouping had the same filter: page loads from the start of the period up to the end of it. That was the only filter.

Why a time filter was not enough

The query asks for data by Cloudflare account, not by website. The commit message for the fix explains why that matters:

Web Analytics-dataene ligger per konto, og kontoen deles med vibeapp.win. Spørringen filtrerte bare på tid, så statussiden viste vibeapp-sider som /apps i kokkekunst-tallene.

In English: Web Analytics data is stored per account, and the account is shared with vibeapp.win. The query filtered only on time, so the status page showed vibeapp pages such as /apps in the kokkekunst numbers.

So any page load measured anywhere on the account was counted. vibeapp.win is on that account. Its page views went into the kokkekunst.no total. Its pages showed up among kokkekunst.no’s. Its referrers and visitor countries were mixed in with kokkekunst.no’s.

How it showed up

A path called /apps showed up among the kokkekunst.no pages in the status page numbers. That page belongs to vibeapp.win.

The totals had no such clue. A page-view count that is too high looks like any other page-view count. The changelog entry for the fix says the total, the referrers and the countries were all too high.

The fix

The fix landed on 6 October 2026. Claude added a list of the hostnames that belong to kokkekunst.no and passed it to the query as a variable. Every grouping got the same extra condition: a host filter, which keeps only page loads whose host is on the list. The list has three entries:

• www.kokkekunst.no
• kokkekunst.no
• the site’s Cloudflare Pages preview address

The preview address stays on the list on purpose. Traffic there is the same site at a different address, and the status page already reports it as a separate footnote under the hostnames rather than blending it into the total. Leaving it out of the filter would have removed that footnote.

The fix applies to all five groupings, not only the list of pages where /apps appeared. Filtering only the path list would have hidden /apps and left the totals, referrers and countries wrong.

A code comment above the list now records the reason it exists and the date it was added, so a later change does not quietly remove the filter.

What changed for the reader of the status page

Two practical points from the changelog:

• The numbers may look lower than before. That is not a drop in traffic. The other site has been taken out.
• Past days are corrected too. The figures are fetched from Cloudflare each time the page loads. Once the query was right, the whole seven-day window was right, including the days before the fix.

Nobody had to do anything to get the correction.

Why this was easy to miss

The query worked. It returned data, the panel rendered, and the shape of the numbers looked believable. The mistake was an assumption: that the data source holds one website’s numbers.

The filter was not missing from just one of the five groupings, where comparing them might have shown the gap. All five had the same time-only filter, so all five were wrong in the same way and agreed with each other.

The rule

When a data source is shared between several sites, always filter on hostname, and filter every query that reads from it, not only the one where the problem showed up. Then check that the numbers belong to what you think they belong to. A path, a referrer or a hostname in the result that cannot exist on your site is a sign that the query is reading more than it should.