Behind the scenes: a 403 that wasn't Cloudflare

On Wednesday, November 4, my browser-based editor started answering anyone off my home network with a single word: Forbidden. It looks exactly like a Cloudflare block, which makes Cloudflare the obvious suspect, and Cloudflare had done nothing wrong at all.

The week in short:

A stale server on port 8010 was handing back 403s, and a fresh one on 8011 fixed it.
A new consistency checker swept 47 of my domains and came back with a short list, from one soft 404 to missing profile links.
About 140 finalise runs went through the news desk across sixteen news sites, including eleven Sail Commons briefs rewritten and run through four gate rounds.
Newsletter edition 12 went up as a guide on Thursday, Ask the AI last.
Saturday's Search Console review turned up three alarms. One of them was real.

Forbidden, but not by Cloudflare

The editor is VS Code running in a browser tab, reachable through a Cloudflare tunnel with an access rule that lets exactly one person in, and that person is me. So when the page said Forbidden after I had logged in successfully, the list of suspects was short.

The clue was that the server's version page answered with a 200 while its front page answered with a 403, and it did that even when I asked it directly from the machine it lives on. Cloudflare was never in that conversation. An older copy of the server had been sitting on port 8010, wrong, and restarting it did not help. The old process's socket stayed bound to the port and I could not even see who owned it.

So I stopped arguing with 8010 and started a fresh server on 8011, which spent about a minute downloading its own newer version while answering 202 to everyone, then pointed the tunnel at the new port. It worked. Port 8010 clears itself when the machine reboots.

Forty-seven domains and one checker

The same day I wrote a script to compare my owned domains against each other, and they had drifted. One site, campgroundseo.com, was answering every path that did not exist with a 200 and its homepage. The Person markup on my lead sites carried anywhere from zero to nine profile links, and I standardized eight of them. Two sites had no HSTS header, and the robots.txt comments on four research sites needed to say what the sites were actually doing.

None of it was dramatic. Each problem is easy to miss on one site and hard to miss with forty-seven sitting in one table. The fixes went out as small overlays, and I checked the Person change live on all eight.

Saturday, with Search Console open

Today I went through Search Console for all 55 properties. The whole portfolio earned 256 clicks, and 87 of them came from a site listing Niagara's Santa Claus parades and craft shows, so that is the business I apparently run now.

Three things got flagged. A parked domain showed its homepage as excluded by a noindex tag, which it is, on purpose. A news sitemap on Sail Commons was marked as an error because it had no articles in it. The file was valid and empty, and Google's own guidance says to list only the last two days of stories, so a quiet stretch will do that. The third was real, a stale sitemap submission for the parked domain, and I removed it.

I also came in with a plan to rewrite the titles on the parade pages, because they ranked around position six and got almost no clicks. Then I read them. They already said the date, the time and the route, which is the reason nobody needed to click. I had a fix ready for a problem that was succeeding.

What I took from it

The 403 was a real fault with the wrong suspect standing next to it. Two of Saturday's three Search Console alarms were accurate readings of things that were fine, and I only know that because I opened the pages before I fixed anything.

If your own Search Console is lighting up and you cannot tell which alarms are real, ask. And if you want the rest of the series, last week's was about a news brief with an expiry date.