DEV Community: Usama Ejaz

Who Drafts, Who Reviews, Who Publishes: A Review Workflow for a Small Company Blog

Usama Ejaz — Fri, 30 Oct 2026 05:51:35 +0000

A company blog with one writer has no process. The same person writes, rereads and hits publish, and nobody notices that three different jobs just happened.

The second writer is where it breaks. Drafts sit in a shared doc waiting for the founder... or someone publishes without a second read and a customer spots the wrong price before anyone on the team does.

I think the fix is smaller than most teams make it. One named person per job, one login per person, and one review pass that ends in a clear yes or a written list of changes.

Three jobs, not three people

Writer. Drafts the post, adds images, and says when it's ready. Usually a marketer, a founder, or whoever is closest to the subject, like a support lead writing up a question customers keep asking.

Reviewer. Reads the draft before anyone outside the company does. The job is catching what the writer can't see: a claim that isn't true any more, a customer named without permission, a paragraph that only makes sense to the person who wrote it. The reviewer approves or sends it back with a comment.

Publisher. Owns the public details and the timing: URL, search title and description, featured image, tags, publish date. On a small team the reviewer usually does this too. It still helps to keep it separate in your head, because "approved" and "live" are different moments.

The one rule that holds it together: the writer shouldn't be the only person who reads a post before it's public. Two people can cover all three jobs as long as that holds.

How small teams usually split it

Team	Writes	Reviews	Publishes
Founder and one marketer	Marketer	Founder	Marketer, after approval
Marketer plus subject experts (engineering, support, sales)	Experts draft, marketer edits	Marketer, plus the expert for accuracy on technical posts	Marketer
Agency or freelancer writing for the company	Agency	Someone at the company	Someone at the company
Founder writes, team member checks	Founder	Whoever knows the topic best	Founder

The agency row is the one to get right first. If an outside writer can publish directly, there's no checkpoint between a contractor's draft and your own domain. Give them access to write and submit, and keep approval and publishing inside the company.

One post, start to finish

1. Draft where it will be published. A draft written in a separate doc has to be pasted in later, and that's where formatting breaks, images go missing and the live version drifts from the approved one. Most blog platforms keep drafts private until publish, so there's no risk in starting there.

2. Submit with a note. "Pricing figures checked against the pricing page on Tuesday" or "not sure about the second section" tells the reviewer where to spend their time. It takes ten seconds and saves a full reread.

3. Approve, or request changes in writing. No "let's discuss". If the reviewer wants changes, they write them down next to the post. The writer gets a list instead of a meeting, and the reasons stay recorded. The writer edits and submits again.

4. Check the public details, then publish or schedule. Approval clears the words. Before it goes out, whoever publishes checks what readers and search engines see first:

Slug. Short and permanent. Changing it after publishing means a redirect.
SEO title and description. The description is what shows under the link in search results and chat previews.
Featured image. It becomes the preview when the post is shared.
Tags or categories. Use ones that already exist. A new tag for one post is a dead end for readers.

If the writer and publisher are in different time zones, check which zone the scheduler uses. "Tuesday 9 AM" is not the same moment for both of them.

Edits to live posts go through review too

A price goes up, a feature gets renamed, a screenshot goes stale. Treat these edits like drafts. A "quick fix" on a live post is exactly how an unreviewed rewrite ends up on the company domain. If your platform keeps revision history, you also get a record of what changed and when.

What the reviewer actually checks

A review that tries to check everything turns into a rewrite, and the writer stops submitting. These are the things a second reader catches that the writer usually can't:

Facts that change. Prices, plan limits, feature names, dates, anything phrased as "currently". These are the claims that cost you a support ticket when they're wrong.
Names and permissions. Any customer, partner or employee named or quoted, and whether they agreed to it.
Promises. Anything that reads as a commitment: delivery times, guarantees, "coming soon".
The reader's next step. Whether someone who reaches the end knows where to go next, and whether that link works.
Clarity for an outsider. Internal shorthand, project codenames, steps the writer skipped because they know them by heart.

Tone, word choice and structure are the writer's call unless something is actually wrong. "I would have written it differently" isn't a reason to send it back.

Separate logins, not a shared one

Every person who writes or reviews should have their own account on the blog. With one shared login you can't tell who changed a live post, and removing one person means changing the password for everyone. It also lets you match permissions to the table above: writers draft and submit, approval and publishing stay with the people who answer for what appears on the domain.

The same applies if you draft with an AI assistant connected to the blog. Connect it with a writer's permissions, not an admin's, so it can draft and submit but can't approve its own work.

When you don't need any of this

If one person writes and publishes everything, the review step is that person rereading the post the next morning. If a colleague only reads a post now and then, pasting it into a shared doc for comments is fine. The setup above starts paying off when a second person needs to draft or publish on their own, or when you stop being sure who changed a live post.

Keeping the queue moving

The most common failure isn't a bad review. It's a draft waiting for review with nobody looking at it.

Agree on a turnaround the reviewer can actually keep, like two working days, and say it out loud. A writer who knows when they'll hear back keeps writing.
Review in batches, publish on a schedule. Approve three posts in one sitting, then schedule them a week apart. Writing, review and publishing run on their own calendars, and the blog keeps publishing through a launch or a holiday.

I run JustBlogged, a blog platform, and this is the flow we built its team reviews around. It works the same on any platform that gives each person their own login

Your Hosted Blog Got an F on a Security Headers Scan: What a Meta Tag Can Actually Fix

Usama Ejaz — Mon, 26 Oct 2026 05:45:03 +0000

Most of the points a security headers scanner takes off a hosted blog are for HTTP response headers. Those come from the host. A theme only controls HTML, and only two of these policies work from HTML at all: a referrer policy via <meta name="referrer"> and a Content Security Policy via <meta http-equiv="Content-Security-Policy">.

HSTS, X-Frame-Options and X-Content-Type-Options only work as real headers. Browsers ignore them in a meta tag.

I run a blog host (JustBlogged), so people send me these reports and ask which lines they can fix themselves. On October 24, 2026 I sat down and actually checked, with the scanner and with a real browser. The part I didnt expect... MDN's HTTP Observatory gives you credit for a frame-ancestors directive in a meta tag, which browsers ignore. Your grade goes up and nothing about framing changes.

How the Observatory scores

The Observatory's scoring is public and its source is on GitHub. Every site starts at 100 and loses points per failed test. Bonuses only apply if you're still at 90 or above after penalties. For a typical hosted blog that means the grade is just 100 minus penalties.

I ran its public API against one blog per platform. Every scan hits the front page, so read these as platform defaults on that day:

Blog tested	Platform	Grade	Where the points went
demo.ghost.io	Ghost(Pro), platform subdomain	F (20)	No CSP -25, no HSTS -20, no X-Frame-Options -20, no X-Content-Type-Options -5, referrer policy -5, SRI -5
www.404media.co	Ghost(Pro), custom domain	F (20)	Same six deductions
en.blog.wordpress.com	WordPress.com	F (20)	No CSP -25, SRI -50, no X-Content-Type-Options -5
octocat.github.io	GitHub Pages	F (10)	No CSP -25, no HTTPS redirect -20, no HSTS -20, no X-Frame-Options -20, no X-Content-Type-Options -5
jamstack.org	Netlify	C- (45)	No CSP -25, no X-Frame-Options -20, no X-Content-Type-Options -5, SRI -5
townhall.hashnode.com	Hashnode	C (50)	No CSP -25, no X-Frame-Options -20, no X-Content-Type-Options -5
herman.bearblog.dev	Bear Blog	C (50)	No CSP -25, invalid X-Frame-Options -20, referrer policy -5
on.substack.com	Substack	B (70)	CSP allows unsafe inline -20, no X-Content-Type-Options -5, SRI -5

A few rows are worth reading before you try to fix anything:

Neither Ghost(Pro) blog sent a single security header, subdomain or custom domain. Ghost's head output includes <meta name="referrer" content="no-referrer-when-downgrade">, which sends the full page URL to other HTTPS sites. The browser default is strict-origin-when-cross-origin, so that tag is less private than sending nothing. Thats the -5.
WordPress.com's -50 is from scripts loaded with protocol-relative URLs like //stats.wp.com/w.js. On an HTTPS page those still load over HTTPS, but the rule penalizes any external script without an explicit https:.
The GitHub Pages site didnt redirect HTTP to HTTPS. Thats the "Enforce HTTPS" checkbox in the repo settings, so ticking it removes that -20.
Bear Blog sends X-Frame-Options: ALLOWALL, which isnt a defined value. The scanner calls it invalid, and in my Chromium test a page with that header framed exactly like a page with no header.

Which deductions a theme can remove

Test	Typical penalty	Works from a meta tag?
Content Security Policy	-25 if missing	Yes, with limits. The CSP spec excludes `frame-ancestors`, `report-uri` and `sandbox` from meta delivery
Referrer Policy	-5 if unsafe	Yes, via `<meta name="referrer">`
Strict-Transport-Security	-20 if missing	No. RFC 6797 section 8.5 tells browsers not to heed it in a meta element
X-Frame-Options	-20 if missing	No. Setting it in a meta tag has no effect
X-Content-Type-Options	-5 if missing	No. Header only
HTTP to HTTPS redirect	-20 if missing	No. Host or server setting
Subresource Integrity	-5 to -50	Only for scripts your theme adds, not ones the platform injects

So on a host that doesnt let you set headers, a theme can win back at most the CSP and referrer points. Thats 30 of the 80 Ghost(Pro) lost. The other 50 have to come from the host.

What Chromium actually does with each meta tag

I ran headless Chromium 153.0.8010.12 through Playwright 1.63.0, served test pages from one local origin and framed them from another. Each protection tried once as a header and once as a meta tag:

Page sent	Loaded in a cross-origin iframe?
No header, no meta tag	Yes
`Content-Security-Policy: frame-ancestors 'none'` header	No, blocked
Same policy in a meta tag	Yes
`X-Frame-Options: DENY` header	No, blocked
`<meta http-equiv="X-Frame-Options" content="DENY">`	Yes
`X-Frame-Options: ALLOWALL` header	Yes

Chromium even tells you in the console:

The Content Security Policy directive 'frame-ancestors' is ignored when delivered via a <meta> element.
X-Frame-Options may only be set via an HTTP header sent along with a document.

The meta tags that are supposed to work did. <meta name="referrer" content="no-referrer"> removed the Referer header from an image request, and with two referrer meta tags on a page the second one won.

The scanner and the browser disagree

The Observatory doesnt treat the ignored frame-ancestors tag the way the browser does. Its HTML parser reads CSP meta tags, and the X-Frame-Options test passes whenever the merged policy contains frame-ancestors, without checking where it came from.

I ran the analyzer's test functions locally against a page whose only protection was a meta CSP with frame-ancestors 'none'. The X-Frame-Options result came back "implemented via CSP" at +5 instead of -20. Thats 25 points for a tag Chromium ignores.

I'd leave it out. It makes the report say your pages cant be framed when they still can.

A meta CSP on a platform that injects its own scripts

The CSP deduction only fully clears when script-src blocks inline scripts. In the analyzer, a policy allowing inline scripts still scored -20 and one limiting scripts to 'self' moved to +5.

On a hosted blog there are inline scripts whether you added them or not. I took a real post on a blog I control, inserted each candidate policy right after <meta charset>, and counted CSP errors in the console:

Policy inserted	CSP errors
None	0
`upgrade-insecure-requests; object-src 'none'; base-uri 'self'`	0
`default-src 'self'; script-src 'self'` plus font, image and style sources	7: three inline scripts, three inline styles, Cloudflare's analytics beacon
Same, with `'unsafe-inline'` added to `style-src`	4: three inline scripts and the beacon

Two of those inline scripts were the blog's own site-level custom code. I could allow them with hashes, but then every edit means updating the hashes.

The third cant be allowed that way at all. Cloudflare's bot detection injects it, it carries a request ID and a timestamp, and its hash changed between two consecutive page loads. Cloudflare's JavaScript detections docs say it copies nonces from a CSP response header into the scripts it injects, and that nonces set through meta tags arent supported. So any blog behind Cloudflare with that feature on hits the same wall. Platform scripts for members, search or analytics are a smaller version of the same problem, since their hashes change whenever the platform updates them.

The policy I'd actually put on a hosted blog is the one with zero errors:

<meta charset="UTF-8">
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests; object-src 'none'; base-uri 'self'">
<meta name="referrer" content="strict-origin-when-cross-origin">

It upgrades leftover http:// subresources, blocks plugin content, and stops injected markup from changing the base URL for relative links. The scanner still takes 20 points for it because scripts arent restricted. I think thats the right trade on a blog you dont fully control... none of it can break the page.

Put the CSP tag as high in <head> as you can. The spec says a meta policy doesnt apply to content before it, and in my test an inline script above the tag ran while the same script below it was blocked.

The referrer tag matches the browser default, so on most platforms it changes nothing. On Ghost it overrides the looser platform tag, as long as yours comes later in the page.

Where those tags go

Ghost: Settings > Code Injection > Site header. Ghost writes its own referrer tag near the top of its head output, so view source after saving and check yours comes after it.
Netlify and Cloudflare Pages: both read a _headers file from the publish directory. These are real headers, so X-Frame-Options, frame-ancestors and X-Content-Type-Options all work there. Cloudflare notes the file doesnt apply to responses from Pages Functions.
GitHub Pages: no custom headers and no headers file. Use the meta tags and tick "Enforce HTTPS".
Self-hosted WordPress: you control the server, so set real headers there. Core's send_frame_options_header() sends X-Frame-Options and frame-ancestors 'self', but it's hooked to the login and admin screens, not public posts.

One caution even where you can set headers: HSTS with includeSubDomains and preload is hard to undo. Dont add preload on a whim.

When the grade is worth a host change

For a blog that just publishes posts, I think the protections that matter most to readers are the HTTPS redirect and HSTS. Both come from the host. If yours sends neither, thats worth raising with them.

CSP, X-Frame-Options and SRI deductions mostly measure how much of the response the host lets you control. Chasing them where you cant set headers ends in either a policy that breaks platform scripts or a meta tag that only fools the scanner.

If a specific grade is a hard requirement, like a client security review, you need a host where you write the headers yourself: Netlify or Cloudflare Pages with _headers, or your own server. And then check it in the Observatory and in the browser console, because as above, the two dont always agree

Post Dates Off by One Day After a WordPress Migration: Jekyll, Hugo and Eleventy Tested

Usama Ejaz — Fri, 23 Oct 2026 05:49:44 +0000

A WordPress post at /2023/04/05/late-post/ shows up at /2023/04/06/late-post/ on the new static site. The timestamp is fine. A tool along the way read the UTC version of the publish time, or converted it into the build machine's zone, and the calendar day moved.

It only hits posts published close to midnight, so checking your three newest posts proves very little.

JustBlogged, the blog platform I run, keeps dates out of post URLs, so I'd never seen this break myself. On October 23, 2026 I pushed one WordPress post through the usual static route: a WXR export, the wordpress-export-to-markdown converter, then Jekyll, Hugo and Eleventy. Each one built with the machine clock set to Los Angeles, UTC and Karachi.

Short version... the day moved at the converter on its defaults, in Jekyll on any machine not set to the post's zone, and in Eleventy on any machine for date-only posts. Hugo kept the day it was given.

Which WordPress date your old URLs came from

WordPress stores two timestamps per post: post_date in the site's own time zone and post_date_gmt in UTC. Dated permalinks use the first one. get_permalink() splits post_date into year, month and day, and the source comment says to read it as local time whatever the server's PHP zone is.

The export carries the same moment three ways. For a post published at 11:30pm on April 5 on a site set to Los Angeles (UTC-7 in April):

<pubDate>Thu, 06 Apr 2023 06:30:00 +0000</pubDate>
<wp:post_date><![CDATA[2023-04-05 23:30:00]]></wp:post_date>
<wp:post_date_gmt><![CDATA[2023-04-06 06:30:00]]></wp:post_date_gmt>

Only wp:post_date has the day that's in the live URL. Anything that reads pubDate or post_date_gmt and writes the date in UTC gives this post April 6.

The converter writes UTC dates unless you pass --timezone

wordpress-export-to-markdown 3.0.6 reads pubDate and applies --timezone, which defaults to utc. It also drops the time unless you pass --include-time. Same export, three runs:

Flags	File written	Front matter
Defaults	`2023-04-06-late-post.md`	`date: 2023-04-06`
`--timezone=America/Los_Angeles`	`2023-04-05-late-post.md`	`date: 2023-04-05`
`--timezone=America/Los_Angeles --include-time=true`	`2023-04-05-late-post.md`	`date: 2023-04-05T23:30:00.000-07:00`

Use the zone from WordPress Settings > General as an IANA name (America/Los_Angeles, Asia/Karachi) and pass --include-time=true. The full timestamp with its offset is the only form all three generators below read back to the right day, and it keeps the time for your feed and datePublished markup.

Same date, three generators

I built two posts in each generator with a /:year/:month/:day/:slug/ style URL, using Jekyll 4.4.1, Hugo 0.168.0 and Eleventy 3.1.7. One post had date: 2023-04-05 23:30:00 -0700. The other had only a date (the 2023-04-05- filename prefix in Jekyll, date: 2023-04-05 in Hugo and Eleventy). Eleventy has no built-in date permalink, so its URL came from a directory data file using getFullYear(), getMonth() and getDate(). No config set a time zone. Each cell is the day that ended up in the URL.

Generator	Post	Built in Los Angeles	Built in UTC	Built in Karachi
Jekyll 4.4.1	23:30 -07:00	05	06	06
Jekyll 4.4.1	Date only	05	05	05
Hugo 0.168.0	23:30 -07:00	05	05	05
Hugo 0.168.0	Date only	05	05	05
Eleventy 3.1.7	23:30 -07:00	05	06	06
Eleventy 3.1.7	Date only	04	05	05

Jekyll keeps the moment but converts it to the build machine's zone before filling in the URL, so the offset in your front matter doesn't protect the day. A laptop in Los Angeles and a CI runner on UTC produce different URLs from the same repo. The Jekyll configuration docs say the default zone comes from the OS locally and from the server's setting on a remote host.

Hugo kept the written offset in every build. Its timeZone setting only decides how to read dates without an offset, and with it unset those came out as UTC. The written day stays in the URL, though templates that print the time will label it UTC.

Eleventy turns every front matter date into a UTC instant. A date with no time becomes midnight UTC, which is still the previous evening anywhere west of London, so local getters on a machine in the Americas put the post on the 4th. The Eleventy dates page lists this as a common pitfall for displaying dates. It hits permalinks built from those dates too.

Pinning each one

Jekyll, in _config.yml. With this line the post went back to /2023/04/05/ on the UTC build:

timezone: America/Los_Angeles

Hugo, in hugo.toml, so offset-less dates are read the way WordPress meant them. My dated URLs were already right without it and stayed right with it:

timeZone = "America/Los_Angeles"

Eleventy, build the URL in a named zone instead of the machine's. Eleventy depends on Luxon, but add it to your own package.json before requiring it. With the converter's full timestamps, this gave /2023/04/05/late-post/ on all three machines:

// posts/posts.11tydata.js
const { DateTime } = require("luxon");

module.exports = {
  permalink: (data) => {
    const d = DateTime.fromJSDate(data.page.date, { zone: "America/Los_Angeles" });
    return `/${d.toFormat("yyyy/LL/dd")}/${data.page.fileSlug}/`;
  },
};

That file needs posts to have a time. On date-only posts it shifts midnight UTC back into Los Angeles time and moves them to the 4th again. If some posts have to stay date-only, build their URL with getUTCFullYear(), getUTCMonth() and getUTCDate() instead.

Listing the posts that moved

This compares the local day in the WordPress export with the day in the new site's sitemap and prints posts that moved or went missing. It assumes the new URLs keep a /YYYY/MM/DD/ segment and end with the WordPress slug.

# date_drift.py: python3 date_drift.py export.xml _site/sitemap.xml
import re, sys, xml.etree.ElementTree as ET

WP = "{http://wordpress.org/export/1.2/}"
DAY = re.compile(r"/(\d{4})/(\d{2})/(\d{2})/")

def old_days(wxr):
    days = {}
    for item in ET.parse(wxr).iter("item"):
        if item.findtext(WP + "post_type") != "post" or item.findtext(WP + "status") != "publish":
            continue
        local_day = item.findtext(WP + "post_date")[:10]   # what WordPress put in the URL
        days[item.findtext(WP + "post_name")] = local_day
    return days

def new_days(sitemap):
    days = {}
    for loc in re.findall(r"<loc>(.*?)</loc>", open(sitemap).read()):
        m = DAY.search(loc)
        if m:
            slug = loc.rstrip("/").rsplit("/", 1)[-1].removesuffix(".html")
            days[slug] = "-".join(m.groups())
    return days

old, new = old_days(sys.argv[1]), new_days(sys.argv[2])
for slug, day in sorted(old.items()):
    if slug not in new:
        print(f"missing  {slug}")
    elif new[slug] != day:
        print(f"moved    {slug}: {day} -> {new[slug]}")

Against the unpinned Jekyll build on UTC it printed moved late-post: 2023-04-05 -> 2023-04-06. After adding timezone it printed nothing. It needs Python 3.9+ and only reads published posts, so drafts and pages don't add noise.

If a post can't go back to its old day, because the new URLs are already indexed or a template depends on the UTC date, redirect each old dated path to the new one wherever your host keeps redirects.

Jekyll and Eleventy can bring the shift back when you change build machines, with zero content changes, so I'd run the script again after any CI move. Picking a URL pattern without the date avoids the whole thing, but most people moving off WordPress don't get to make that choice

Heading Anchors After a Blog Migration: 12 Headings Through 9 Markdown Renderers

Usama Ejaz — Thu, 22 Oct 2026 05:44:59 +0000

A 301 keeps the #section part of a link. Your new page usually doesn't.

When someone opens /old-post/#step-3 and the server answers with a 301 to /new-post/, the browser carries #step-3 over to the new address, per RFC 9110 section 10.2.2. The reader lands on the right section only if the new page has an element with exactly that ID. The server can't fix it either... the fragment is never sent in the request (RFC 9110 section 17.11), so no redirect rule can rename it.

So it comes down to how the old and new platforms turn heading text into an id. While writing migration docs for JustBlogged, the blog platform I run, I wanted actual answers instead of guesses. On October 22, 2026 I ran the same 12 headings through nine renderers.

Jekyll, Hugo, Astro and pandoc's GFM mode gave identical IDs for all 12. Ghost, Python-Markdown (what MkDocs uses), pandoc's default Markdown, Eleventy's IdAttributePlugin and markdown-it-anchor's defaults each disagreed with them on several.

What the browser does with #section after a redirect

I served two test pages from a local Python server, with /old/ answering 301 to the new page, and opened /old/#example-1 in Chromium 141 through Playwright. The address bar ended on the new URL with #example-1 still attached, and the page scrolled to that heading.

With a fragment the new page didn't have, the URL kept it and the page just stayed at the top. No error. That's why broken anchors go unnoticed after a migration: the page loads, the link checker sees a 200, and the reader scrolls around looking for the section.

One browser rule helps when the old IDs were encoded. The HTML standard's fragment-scrolling steps look for an element whose ID equals the fragment as written, and if none exists, try again with the percent-decoded fragment. So #caf%C3%A9-menus finds id="café-menus". That matters for Ghost, which writes percent-encoded IDs.

How nine renderers turned the same headings into IDs

The test post had 12 H2 headings picked to hit the usual differences: punctuation, a straight and a curly apostrophe, accents, an emoji, Japanese text, a spaced hyphen, underscores, a code span and a repeated heading.

Versions: Jekyll 4.4.1 (kramdown 2.5.2 with the GFM parser, Jekyll's default), Hugo 0.168.0 on defaults, Astro's Markdown pipeline (@astrojs/markdown-remark 7.3.4), pandoc 3.1.3 in both markdown and gfm modes, Python-Markdown 3.11.2 with the toc extension, markdown-it 15.0.3 with markdown-it-anchor 10.0.0 on defaults, Eleventy 3.1.7 with IdAttributePlugin on, and Ghost's @tryghost/kg-lexical-html-renderer 1.4.5. The Ghost column comes from that renderer package run directly, not a live Ghost site.

Two headings came out the same everywhere: Using `noindex` on tag pages became using-noindex-on-tag-pages, and the first of two "Example" headings became example. The other ten split like this ("same" means identical to the first column):

Heading	Jekyll, Hugo, Astro, pandoc gfm	Ghost	Python-Markdown	Eleventy IdAttributePlugin	markdown-it-anchor default	pandoc markdown
Set up DNS (A/AAAA records)	`set-up-dns-aaaaa-records`	same	same	`set-up-dns-a-aaaa-records`	`set-up-dns-(a%2Faaaa-records)`	same
What's new in v2.0?	`whats-new-in-v20`	same	same	`whats-new-in-v2-0`	`what's-new-in-v2.0%3F`	`whats-new-in-v2.0`
Ghost's 404 page (curly apostrophe)	`ghosts-404-page`	`ghost%E2%80%99s-404-page`	same	`ghost-s-404-page`	`ghost%E2%80%99s-404-page`	same
C++ & C#	`c--c`	`c-c`	`c-c`	`c-and-c`	`c%2B%2B-%26-c%23`	`c-c`
Café menus, naïve UTF-8	`café-menus-naïve-utf-8`	`caf%C3%A9-menus-na%C3%AFve-utf-8`	`cafe-menus-naive-utf-8`	`cafe-menus-naive-utf-8`	`caf%C3%A9-menus%2C-na%C3%AFve-utf-8`	same
(rocket emoji) Launch notes	`-launch-notes`	`%F0%9F%9A%80-launch-notes`	`launch-notes`	`launch-notes`	`%F0%9F%9A%80-launch-notes`	`launch-notes`
日本語の見出し	`日本語の見出し`	percent-encoded form of the same text	`_1`	empty `id=""`	percent-encoded form of the same text	same
Example (second time)	`example-1`	same	`example_1`	`example-2`	same	same
Step 1 - Install	`step-1---install`	`step-1install`	`step-1-install`	`step-1-install`	same	same
snake_case_names	`snake_case_names`	`snakecasenames`	same	`snake-case-names`	same	same

Eleventy only adds heading IDs if you opt in to its IdAttributePlugin, which uses the built-in slugify filter and @sindresorhus/slugify. An Eleventy site that wired up markdown-it-anchor itself follows whatever slug function its config passes in, so check yours.

Ghost's rules are short enough to read in its slugify source: remove ASCII punctuation including underscores, replace spaces with hyphens, delete any run of two or more hyphens outright, then percent-encode.

Which moves keep their anchors

Jekyll, Hugo and Astro on default settings kept every anchor between each other, because all three follow GitHub's heading rules: Jekyll's default config sets kramdown's input to GFM, Hugo's autoIDType defaults to github, and Astro uses github-slugger. A Jekyll site on kramdown's plain parser, or a Hugo site set to github-ascii or blackfriday, is outside what I tested.

Ghost to one of those is mixed. Plain letters, digits and spaces matched, and so did parentheses, a straight apostrophe and a question mark. Accents and Japanese text also worked in Chromium through the percent-decoding rule: /old/#caf%C3%A9-menus-na%C3%AFve-utf-8 landed on id="café-menus-naïve-utf-8". A curly apostrophe, an emoji, an underscore, a spaced hyphen or & sent the reader to the top of the page.

Python-Markdown and Eleventy's plugin transliterate accents to ASCII, so "Café menus" breaks in either direction between them and a GitHub-style generator. Python-Markdown gave the Japanese heading _1, and Eleventy wrote an empty id="" that no link can reach. Eleventy also numbers a repeated heading from 2, so the second "Example" became example-2 where everything except Python-Markdown wrote example-1. markdown-it-anchor's default keeps punctuation and percent-encodes most of it, so almost any heading with punctuation changes when you leave it.

WordPress core doesn't add heading IDs at all. Anchors on a WordPress post came from the heading block's HTML anchor field or a table-of-contents plugin, each with its own format. You can't predict those from the heading text, so read them out of the old pages.

List the IDs your new pages are missing

Run this before you change DNS, while the old site still answers. It reads a CSV of old_url,new_url pairs (the redirect map you need anyway), fetches both pages, and prints every id or name on the old page with no match on the new one. A percent-decoded match counts as found, same as the browser. Standard library only.

# Usage: python3 anchor_diff.py redirects.csv
# Each CSV row: old_url,new_url
import csv, sys, urllib.request
from html.parser import HTMLParser
from urllib.parse import unquote

class IDs(HTMLParser):
    def __init__(self):
        super().__init__()
        self.ids = set()
    def handle_starttag(self, tag, attrs):
        for name, value in attrs:
            if name in ("id", "name") and value:
                self.ids.add(value)

def ids_at(url):
    req = urllib.request.Request(url, headers={"User-Agent": "anchor-diff"})
    with urllib.request.urlopen(req) as r:
        p = IDs()
        p.feed(r.read().decode("utf-8", "replace"))
        return p.ids

for old, new in csv.reader(open(sys.argv[1])):
    new_ids = ids_at(new)
    reachable = new_ids | {unquote(i) for i in new_ids}
    for i in sorted(ids_at(old)):
        if i not in reachable and unquote(i) not in reachable:
            print(f"{old}#{i}\tmissing on {new}")

On my Ghost-rendered test page and its Astro-rendered replacement it printed five IDs: the curly apostrophe, the emoji, c-c, snakecasenames and step-1install. The same five fragments that left Chromium at the top of the page. On a real site you'll also get theme IDs like navigation, comment and footnote anchors... skim past the ones nobody links to.

Not every missing ID needs fixing. The ones worth keeping are linked from somewhere: your own posts (search your export for href values containing #), docs or forum threads pointing at a section, anything you shared yourself. A heading nobody linked to can take the new ID.

Keep the old ID on the new page

Two ways: set the heading's ID explicitly, or leave the new ID alone and put an empty element with the old ID right before the heading. I built both in Jekyll, Hugo, Astro and pandoc.

Jekyll and pandoc accept an explicit ID after the heading text: ## Step 1 - Install {#step-1install}. Both produced <h2 id="step-1install">, per kramdown's header ID syntax.
Hugo accepted the same {#step-1install} syntax with no config change. It dropped raw HTML from Markdown though, because renderer.unsafe defaults to false, so the empty-element alias won't survive unless you change that.
Astro didn't understand {#...}. It slugged the braces into the ID and produced step-1---install-step-1install. Writing the heading as raw HTML, <h2 id="step-1install">Step 1 - Install</h2>, kept the ID, and so did an empty element before a Markdown heading.
Python-Markdown can take an explicit ID through the attr_list extension, per its toc documentation. I didn't build that case.

The empty-element alias lets the heading keep its new clean ID while old links still land:

<span id="ghost%E2%80%99s-404-page"></span>
## Ghost's 404 page

Copy the old ID exactly as the script prints it, percent signs included. In Chromium that span caught both #ghost%E2%80%99s-404-page and the typed curly-apostrophe version, because the browser encodes the typed character before matching.

I still haven't tested Jekyll on kramdown's plain parser or Hugo's other autoIDType values, so if you're on one of those, run the script before you trust the table

What a Password-Protected Blog Post Still Leaks: WordPress 7.1.3 and Hugo Tested

Usama Ejaz — Wed, 21 Oct 2026 05:42:38 +0000

A password on a WordPress post hides the body and the excerpt. That's it.

The title, the URL, the date and the featured image are still public, and WordPress keeps listing the post in its sitemap, its RSS feed and its REST API. On a static site it's looser... the host's password covers the page, but the generator already copied the post's text into your feed.

JustBlogged, the blog platform I run, doesn't have per-post passwords, so I wanted to see what the platforms that do actually hide. On October 21, 2026 I installed WordPress 7.1.3 locally with the default Twenty Twenty-Five theme, published one protected post with a featured image, and requested every public address that could mention it from a logged-out terminal. Then I did the same with a Hugo 0.168.0 build.

What a logged-out visitor got from WordPress

The post was titled "Client notes Q3". Its body and its hand-written excerpt each had a marker word in them, and it had an uploaded featured image. Neither marker word showed up anywhere. Everything else did:

Address	What came back
The post URL	200, the heading "Protected: Client notes Q3", the password form, and the featured image
Home page	The post in the latest-posts list, with title and featured image
`/feed/`	An item titled "Protected: Client notes Q3" with link and date, the description "There is no excerpt because this is a protected post.", and the password form as content
`/wp-sitemap-posts-post-1.xml`	The post's URL, next to the public posts
`/wp-json/wp/v2/posts/5`	Title, link, date and `featured_media` ID, with `content` and `excerpt` empty and `"protected": true`
`/wp-json/wp/v2/media?parent=5`	The featured image's record and its direct file URL
The image file in `/wp-content/uploads/`	200, no password asked
`/client-notes/embed/`	The prefixed title and the protected-excerpt sentence
Site search for a marker word	No results

This matches WordPress's own password protection docs: the password replaces the content and excerpt and adds "Protected: " to the title. The same page warns that custom fields aren't covered, so a theme or plugin that prints post meta will print it on a protected post unless it checks post_password_required().

Search coming back empty is on purpose. For logged-out visitors WP_Query adds a post_password = '' condition to every search.

Two details for readers who do have the password:

The protected post was sent with Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private. A public post got no cache header at all. So a page cache that respects headers won't serve one reader's unlocked copy to the next person.
The password lives in a wp-postpass_ cookie that lasts 10 days by default, changeable with the post_password_expires filter. WordPress only remembers one password at a time, so opening two posts with different passwords means typing the first one again.

Getting the post out of the feed, sitemap and listings

The WordPress docs include a snippet that removes protected posts from every query except their own page. I saved it as a must-use plugin at wp-content/mu-plugins/hide-protected.php:

<?php
function exclude_protected( $where ) {
    global $wpdb;
    return $where .= " AND {$wpdb->posts}.post_password = '' ";
}

function exclude_protected_action( $query ) {
    if ( ! is_single() && ! is_page() && ! is_admin() ) {
        add_filter( 'posts_where', 'exclude_protected' );
    }
}
add_action( 'pre_get_posts', 'exclude_protected_action' );

With it on, the post was gone from the home page, the feed, the sitemap and the REST API's post list. Its own URL still showed the password form.

Two things didn't change. /wp-json/wp/v2/posts/5 still returned the title to anyone asking for that ID, and the media endpoint still listed the image with its file URL.

The image is the part no query filter reaches. Files in wp-content/uploads are normally served straight by the web server without WordPress running, so there's no password check, and the default theme draws the featured image on the password page itself. If a picture has to stay private I wouldn't make it the featured image or upload it to a public site's media library at all. Same with the title and slug... if the subject alone gives it away, the title has to be neutral before you publish.

Static sites: the page is protected, the feed isn't

A static site has no server code to check a password, so protection comes from the host. Netlify has a shared-password visibility setting on Pro and Enterprise according to its knowledge base (as of October 21, 2026). Cloudflare Access can put a login in front of an app on a domain in your Cloudflare account. On your own server, basic auth does the same.

All of these protect the paths you give them. The generator already wrote the post into files at other paths.

In my Hugo build, with minimal templates and no theme, the default output put the post's text in both /index.xml and /posts/index.xml, and its URL in /sitemap.xml. A password rule on /posts/client-notes/ covers none of those.

One build option in front matter took it out of both feeds, the sitemap and the section listing, while the page still rendered:

---
title: Client notes Q3
build:
  list: never
---

Hugo's build options docs say list: never keeps the page out of every page collection, and the built-in feed and sitemap templates read from those collections. A theme can build its feed, related posts or search index its own way though, so I'd rebuild and grep the output folder for a phrase from the post before trusting it.

Pagefind is the one that catches people. It reads the built HTML, not Hugo's collections, so an unlisted page that still renders still gets indexed. Its indexing docs recommend marking the pages you want indexed with data-pagefind-body, which drops every page without it. Other generators have the same problem in whichever plugin writes the feed, sitemap and search index.

Ghost doesn't do per-post passwords

Ghost restricts posts by membership instead: public, members only, paid members only, or specific tiers, per its protected content guide. Readers get in by signing in. The only shared password is Private Site Mode, which covers the whole site, and Ghost's RSS help page says the public feed is off while that's on, with a private feed URL under Settings, General, "Make this site private".

Which one fits

A WordPress post password is fine when the title and the fact the post exists can be public and only the body matters, like a client update or a family post. With the snippet above it stays out of the feed and sitemap. The featured image still needs to be neutral or gone.

A shared password also gets forwarded along with the link. It keeps search engines and casual visitors out, and tells you nothing about who actually read it.

When the post's existence has to stay hidden too, WordPress's Private status went further in my test: 404 for logged-out visitors, not in the sitemap, 401 from the REST API. But the docs limit private posts to Administrators and Editors, so it's for notes to yourself or a co-editor, not readers. For a group of readers you need a real login (Ghost members, or a host-level rule on a separate path) plus the feed, sitemap and search exclusions above.

Anything that would do real damage if the password leaked I wouldn't put on a public blog's server at all

Edited a Blog Post but Readers Still See the Old Version? How to Find the Cache Holding It

Usama Ejaz — Tue, 20 Oct 2026 05:47:46 +0000

You fix a typo in a published post, reload, and it's fixed. Then someone replies with a screenshot of the old version.

Something between the host and that reader is serving a stored copy. It's one of four places: the reader's browser, the host's CDN edge, a page cache on the host's servers, or a copy kept on some other service entirely (a social preview, a feed reader, Google). The first three show up in the post's response headers, so that's where I start.

On October 20, 2026 I pulled the headers from public blogs on nine platforms. Edge lifetimes went from 25 seconds on Hashnode to 12 hours on Bear. And the usual trick of adding a query string to bust the cache only worked on two of the four CDNs I tried it on.

One curl command

Run it against the public URL, from a terminal that isn't logged in to the blog:

curl -s -o /dev/null -D - https://yourblog.com/your-post/ \
  | grep -iE '^(cache-control|age|cf-cache-status|x-vercel-cache|cache-status|x-cache|last-modified):'

What I look at:

cache-control: max-age=N lets a browser reuse its copy for N seconds without asking. s-maxage=N does the same for shared caches like a CDN, and RFC 9111 says it overrides max-age there.
no-cache or max-age=0 means a stored copy has to be revalidated before reuse. It does not mean "don't store it", which MDN's caching guide is clear about.
age is how many seconds the copy has been sitting in a shared cache. age: 5961 is an edge copy about 100 minutes old.
The cache-status header tells you if the edge answered from storage. The name depends on the CDN: cf-cache-status on Cloudflare, x-vercel-cache on Vercel, cache-status on Netlify, x-cache on Fastly. HIT means a stored copy.

What nine platforms sent

One or two requests per platform, to a real site on it. It's a snapshot... hosts change these, and individual sites add their own rules. Medium gave me a 403, so it's not here.

Platform	Site checked	Cache-Control on the post HTML	Edge signal	How long an old copy can live
GitHub Pages	karpathy.github.io, jekyllrb.com	`max-age=600`	`x-cache` via Fastly (Varnish)	10 minutes in a browser that already loaded it
Netlify	docs.netlify.com	`public, max-age=0, must-revalidate`	`cache-status: "Netlify Edge"`	Until the next deploy, which Netlify says clears the CDN cache
Vercel	nextjs.org/blog	`public, max-age=0, must-revalidate`	`x-vercel-cache: HIT`, `age: 7426`	Until the next deployment, which gets its own cache key
Hashnode	townhall.hashnode.com	`public, s-maxage=25`	`x-vercel-cache: MISS`	25 seconds at the edge
Ghost(Pro)	404media.co	`public, max-age=0`	`x-cache: MISS, HIT, HIT`, `age: 8531`	Browsers revalidate every time; the edge copy depends on Ghost(Pro) purging it
WordPress.com	wordpress.com/blog	`max-age=137, must-revalidate` (156 on an earlier request)	`x-nananana: Batcache-Hit`	About two and a half minutes in a browser
Substack	on.substack.com	`no-cache`	`cf-cache-status: HIT`, `age: 1470`	Edge copy kept despite `no-cache`; lifetime not exposed
Bear	herman.bearblog.dev	`public, s-maxage=43200, max-age=0`	`cf-cache-status: HIT`, `age: 5842`	Up to 12 hours at the edge unless Bear purges on edit

I couldn't find current docs on when Ghost(Pro) or Bear purge the edge after an edit. The closest thing is a 2019 reply on the Ghost forum saying their custom X-Cache-Invalidate header is used on Ghost(Pro)'s caching layer. So the header test on your own post is the only reliable answer I have.

Step 1: rule out the browser

Only GitHub Pages and WordPress.com in that table give browsers a positive max-age. Inside that window, a browser that already has the page can show its stored copy when you click back to the post.

A normal reload sends Cache-Control: max-age=0 with the stored validators, so the browser checks with the server first. A force reload (Ctrl+Shift+R, Cmd+Shift+R on a Mac) sends no-cache and skips the stored copy. If either one shows the edit, it was the browser, and everyone else's browser catches up within the max-age. That's 10 minutes at most on GitHub Pages.

Step 2: check the edge copy's age

If a force reload still shows the old text, and the response has a HIT with an age longer than the time since your edit, the edge copy was stored before you saved. How long it stays is s-maxage or whatever rules the CDN has. On Bear that's 43,200 seconds.

Substack's row is the odd one. Cloudflare's docs say it doesn't cache HTML by default and skips responses marked no-cache. So a HIT on no-cache HTML means Substack set its own cache rule, with a lifetime the response doesn't tell you.

To confirm the edge is the problem, request the post with a throwaway query string like ?nocache=21404. The result depended on the CDN:

Platform	Plain URL	With a random query string
Bear	`HIT`, `age: 5961`	`MISS`
Substack	`HIT`, `age: 1600`	`MISS`
GitHub Pages	`HIT`	`HIT`
Ghost(Pro)	`HIT`, `age: 8531`	`HIT`, `age: 8651`

On Bear and Substack the query string went to the origin. If that version has your edit and the plain URL doesn't, the edge copy is stale and gets replaced when it expires or the host purges it.

On GitHub Pages and Ghost(Pro) it still came back as a hit, and on Ghost(Pro) the age kept counting up. The cache was ignoring the query string. On those hosts this test can't tell the edge from the origin, which I think a lot of "just add ?v=2" advice misses.

If you put your own Cloudflare proxy in front of a hosted blog, you now have two edge caches with separate rules stacked on each other. Check both.

Step 3: check logged out

Page caches often treat signed-in visitors differently. The Batcache readme, which is the cache behind Batcache-Hit on WordPress.com, says it works "by serving old pages to new users," and that once visitors "have logged in or left a comment they will always get fresh pages."

So if you're signed in to your own blog, you see the edit and logged-out readers get the stored page. A private window or the curl above carries none of your cookies.

Step 4: the copies that aren't on your host

If the post URL serves the new version and someone still sees the old one, the copy lives on another service, and each one refreshes on its own schedule:

Link previews on social networks and chat apps keep the title, description and image they fetched first.
Feed readers only see the edit after they poll your feed again, which can be hours for a small blog.
Google's title and snippet come from its last crawl. Search Console's URL Inspection tool lets you run a live test and request indexing. Google says that "typically takes only a day or so" but can take longer, and requests have a daily limit.

I build JustBlogged, and when I ran the same curl on its post pages they came back with no Cache-Control, no age, no cache-status header and no Last-Modified. Nothing tells a browser or CDN to keep the page, so when someone there reports an old version it's always step 4. The flip side is every request goes to the origin, and I'm still not sure that's the right default

Why New Blog Posts Reach Feed Readers Hours Late, and Which Platforms Send a WebSub Hub

Usama Ejaz — Mon, 19 Oct 2026 05:46:43 +0000

A new post shows up in a feed reader only when the reader next fetches your feed. Most readers fetch on a schedule, and for a small blog that schedule is slow. Feedly's free plan checks a feed anywhere from every 30 minutes to once a day.

The way around it is a WebSub hub. Your feed names a hub, your platform pings it when you publish, and readers subscribed to the hub get the post when the hub pushes it. On October 19, 2026 I fetched one feed from each of ten blogging platforms to see which ones declare a hub. Three did.

How often readers actually check

These come from each reader's own docs as of October 19, 2026.

Reader	How often it polls	Source
Feedly Basic	30 minutes to 1 day, depending on how popular the site is and how often it publishes	Feedly help
Feedly Pro	15 minutes to 1 hour	same
Feedly Pro+ and Enterprise	As often as every 7 minutes	same
Inoreader	Active feeds every 30 minutes to a few hours; few subscribers at most hourly; quiet for a month about daily	Inoreader feed fetcher
Miniflux (self-hosted)	Round-robin with a 60-minute minimum by default; the optional `entry_frequency` scheduler adapts from 5 minutes to 24 hours based on the last week	Miniflux configuration

The popularity factor is what hurts a personal blog. A handful of subscribers on free accounts puts you at the slow end of every schedule, and publishing once a week makes you look like a feed that rarely changes.

Both Feedly and Inoreader say what skips the schedule. Feedly says sites using "the PuSH protocol" show up "in near real-time." Inoreader says that when it finds a hub it "receives new items as soon as you publish them" and falls back to polling every few hours.

What a hub changes

WebSub is the W3C Recommendation that grew out of PubSubHubbub, the "PuSH" Feedly mentions. Three parties:

Your feed advertises a hub with rel="hub" and its own address with rel="self".
A reader that supports WebSub subscribes to the hub for that feed.
When you publish, your platform tells the hub, and the hub fetches the feed and pushes it to every subscriber.

The spec leaves one step open: "The specific mechanism for the publisher to inform the hub is left unspecified." In practice the public hubs accept the same thing, a form POST with hub.mode=publish and hub.url set to your feed. That's documented on Google's public hub, which anyone can use without an account.

It doesn't help readers that never look for a hub, and it doesn't stop polling. It removes the wait for the readers that support it.

Which platforms declare one

One public feed per platform. I looked for rel="hub" in the XML and in response headers. I also sent each response's ETag and Last-Modified back as If-None-Match and If-Modified-Since, which is what Inoreader says its fetcher does, to see if the server answers an unchanged feed with 304 Not Modified. A 304 doesn't speed up delivery, but without it every poll downloads the whole file.

Platform (feed checked)	Hub	304 on an unchanged feed
Medium (`medium.com/feed/@ev`)	Yes, `http://medium.superfeedr.com`	No validators sent
WordPress.com (`wordpress.com/blog/feed/`)	Yes, `https://wordpress.com/blog/?pushpress=hub`	Yes
Blogger (`blog.chromium.org/feeds/posts/default`)	Yes, `http://pubsubhubbub.appspot.com/`	No, sent `Last-Modified` but answered the replay with 200
Self-hosted WordPress 7.2 alpha (`wordpress.org/news/feed/`)	No	Yes
Ghost 6.71 (`404media.co/rss/`)	No	Yes
Substack (`lennysnewsletter.com/feed`)	No	Yes
Bear (`herman.bearblog.dev/feed/`)	No	Yes
DEV (`dev.to/feed/ben`)	No	Yes
Hashnode (`townhall.hashnode.com/rss.xml`)	No	No validators sent
JustBlogged (`justblogged.com/blog/rss.xml`)	No	No validators sent

One feed per platform is a sample. A self-hosted WordPress or Ghost site can behave differently because of plugins, themes or the cache in front of it. Several Blogger blogs I tried redirected their feed to FeedBurner, which serves its own copy, so check the URL your readers are actually subscribed to.

The last row is mine. I build JustBlogged, and its own blog feed carries every full post, 594,833 bytes this morning, with no hub, no ETag and no Last-Modified. So readers of that blog wait for their reader's schedule, and every poll downloads the whole file.

Check your own feed

First, does it declare a hub? Either as a link in the XML or as an HTTP Link header, which the spec says subscribers check first.

FEED=https://example.com/feed.xml
curl -sSL "$FEED" | grep -io '<[a-z:]*link[^>]*rel=.hub.[^>]*>'
curl -sSIL "$FEED" | grep -i '^link:.*hub'

Second, does it answer 304 when nothing changed? This sends back both validators the way a reader would:

H=$(curl -sS -D - -o /dev/null "$FEED")
ETAG=$(echo "$H" | grep -i '^etag:' | cut -d' ' -f2- | tr -d '\r')
LM=$(echo "$H" | grep -i '^last-modified:' | cut -d' ' -f2- | tr -d '\r')
curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "If-None-Match: $ETAG" -H "If-Modified-Since: $LM" "$FEED"

Send both headers. WordPress.com answered 304 to If-Modified-Since but 200 to its own ETag alone, so a one-header test can report a failure real readers never hit.

While the headers are open, look at cache-control and age. The Bear feed came back with s-maxage=43200 and a Cloudflare cache hit, which lets the edge keep a copy for up to 12 hours. I didn't check whether Bear purges it on publish. On any host, if the feed is cached at a CDN and not purged on publish, the new post isn't in the feed readers fetch, and no hub fixes that. Fetch your feed right after publishing and confirm the item is there.

Adding a hub yourself

Self-hosted WordPress: the WebSub plugin (4.0.1, 100,000+ active installs as of October 2026) adds hub links to your feeds and pings hubs on publish and update. It uses Google's hub, Superfeedr and WebSubHub by default.

Static site generator: two edits. Add the hub link next to rel="self" in your RSS channel, with the Atom namespace on <rss>:

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link rel="self" type="application/rss+xml" href="https://example.com/feed.xml"/>
    <atom:link rel="hub" href="https://pubsubhubbub.appspot.com/"/>
    ...

Then ping at the end of your deploy, after the new feed is live:

curl -sS -o /dev/null -w '%{http_code}\n' -X POST https://pubsubhubbub.appspot.com/ \
  -d hub.mode=publish \
  --data-urlencode hub.url=https://example.com/feed.xml

A 204 means the hub accepted the ping, not that anyone got notified. I sent that request for a feed with no hub link at all and Google's hub still answered 204. Delivery only happens for readers that found the hub in your feed and subscribed, so the link has to be live first. And rel="self" has to be the exact URL subscribers use, because that's the topic the hub tracks.

On a hosted platform without a hub there's no setting to flip. Your subscribers' readers poll on their own schedule

Leaving WordPress With AMP: Find Every /amp/ and ?amp=1 URL Before the Old Site Goes Offline

Usama Ejaz — Mon, 19 Oct 2026 05:46:07 +0000

If your WordPress blog ever ran an AMP plugin, every post had a second address. Usually /post-name/amp/ or /post-name/?amp=1. Those URLs are still in Google's index and in old shares, and once you move to a host without AMP the /amp/ ones start returning 404.

Google's steps for removing AMP pages while keeping the canonical page are short: take the rel="amphtml" link off the canonical page, and answer each AMP URL with a 301 or 302 to that canonical page.

The hard part is knowing which AMP URLs exist. I read the source of the two main AMP plugins to find out, and wrote a small script to list them. Everything below was checked on October 18, 2026.

Which format your site used

It depends on the plugin and one setting. I downloaded the current releases from WordPress.org and read the code that builds each URL. Examples assume /%postname%/ permalinks and AMP enabled for that content type.

Plugin and setting	Post	Page
AMP 2.5.5, Query parameter (default for new installs)	`/post-name/?amp=1`	`/about/?amp=1`
AMP 2.5.5, Path suffix	`/post-name/amp/`	`/about/amp/`
AMP 2.5.5, Legacy transitional	`/post-name/?amp`	`/about/?amp`
AMP 2.5.5, Legacy reader	`/post-name/amp/`	`/about/?amp`
AMP for WP 1.1.19, default with pretty permalinks	`/post-name/amp/`	`/about/amp/`
AMP for WP 1.1.19, "Change End Point to ?amp" on	`/post-name/?amp`	`/about/?amp`

The official AMP plugin lists 300,000+ active installs and was last updated in April 2025. AMP for WP lists 70,000+ and was updated on October 13, 2026.

Legacy reader is the one that surprised me. It uses /amp/ for posts but falls back to ?amp for pages, attachments, and any URL that already has a query string... so one site can carry both shapes. If you switched the setting at some point, both shapes may also be indexed from different years.

Fastest way to tell: open any post's HTML source on the old site and search for amphtml. The link it prints is the exact AMP URL for that page.

List every AMP URL while WordPress is still up

The amphtml link is the best inventory you'll get, and it only exists while WordPress is serving pages. This reads one sitemap, fetches each URL, and writes the AMP address next to the canonical one:

#!/usr/bin/env bash
# Usage: ./amp-map.sh https://old-blog.example.com/wp-sitemap-posts-post-1.xml > amp-map.csv
curl -s "$1" | grep -o '<loc>[^<]*' | sed 's/<loc>//' | while read -r page; do
  amp=$(curl -s "$page" | grep -o '<link[^>]*rel="amphtml"[^>]*>' \
    | sed -E 's/.*href="([^"]+)".*/\1/' | head -1)
  [ -n "$amp" ] && echo "$amp,$page"
done

I ran it against five posts on ampforwp.com, the AMP for WP plugin's own site, and every row came back the same shape, e.g. https://ampforwp.com/the-change/amp/,https://ampforwp.com/the-change/.

Run it once per post sitemap. WordPress core lists them at /wp-sitemap.xml, Yoast at /sitemap_index.xml. If AMP was on for pages, categories or the home page, run those sitemaps too.

It only sees pages that print the link today. For posts where AMP was turned off earlier but the AMP URL is still indexed, the AMP status report in Search Console lists the AMP URLs Google knows about.

Optional: let the plugin redirect before you move

If WordPress stays up for a few weeks before the DNS change, the official AMP plugin can do Google's two steps for you. In its code, when a URL is requested with the AMP endpoint but AMP isn't available for that content, it redirects to the non-AMP URL and prints an HTML comment in place of the amphtml link. So you leave the plugin active, turn AMP off for your content types under Supported Templates, and the old AMP URLs start redirecting while the posts are still on WordPress.

Two things to know when you test it:

It sends a 302 to anyone with manage_options and a 301 to everyone else. Test logged out, or with curl.
A path-suffix URL can take two hops. With AMP off for posts I saw /post-name/amp/ 301 to /post-name/?amp=1, which then 301'd to the post. Crawlers follow both, but the redirects you add on the new host should go straight to the final URL.

I didn't check whether AMP for WP does the same.

Redirect the /amp/ paths on the new host

After the cutover, WordPress isn't answering anymore, so the redirects have to live wherever the posts went. The two shapes behave very differently there.

The query forms (?amp=1, ?amp) often just load the normal post, because many hosts ignore query parameters they don't use. That's what I got testing on JustBlogged, the blog host I run: 200, the normal post, canonical pointing at the clean URL. Google asks for a redirect, so this isn't an exact match, but I'm fine with it. The page isn't AMP, has no amphtml link, and its canonical names the clean URL, which is the same signal Google uses to consolidate duplicate URLs like tracking-parameter variants.

The path forms (/post-name/amp/, /post-name/amp) are the real problem. They 404, and a 404 drops whatever links and indexing those URLs had. Each one needs a 301.

Point the redirect at the post's new path, not its old WordPress URL. If the old permalink was /2023/05/post-name/ and the post now lives at /post-name, the redirect is /2023/05/post-name/amp/ to /post-name. One hop instead of two.

Google warns against one shortcut: emptying the AMP file instead of redirecting it. An empty document is invalid AMP, and Google keeps serving the oldest valid version it has.

Check every AMP URL after DNS moves

cut -d, -f1 amp-map.csv | while read -r u; do
  curl -s -o /dev/null -w "%{http_code} $u -> %{redirect_url}\n" "$u"
done

Every path-form row should be a 301 to the new post URL, and that URL should be 200. A 404 is a missing or mistyped redirect. A redirect to the old WordPress URL is a chain you can shorten.

After that, the AMP status report's count of indexed AMP pages should drop as Google recrawls them, and the redirected AMP URLs should show up under "Page with redirect" in the Page indexing report

Search Console's "Why Pages Aren't Indexed" on a Blog: Which Rows Actually Need Work

Usama Ejaz — Mon, 19 Oct 2026 05:45:31 +0000

The first time I opened the Page indexing report for a blog I run, the "Why pages aren't indexed" table had more URLs in it than the blog had posts. That looked bad. It mostly wasn't.

An http:// address that redirects, a ?utm_source= link whose canonical points at the clean URL, an RSS feed sent with a noindex header... all of those land in that table, and none of them should be in search results anyway. Google's Page indexing report documentation says the same: most sites have some unindexed pages, and that's fine as long as you understand the reason and your important pages are indexed.

The rows that need work are the ones holding a URL you actually want in search. On a blog that almost always means a post.

Sort by URL first, reason second

Open Indexing, then Pages, and click a row in "Why pages aren't indexed". The details page lists example URLs for that reason, capped at 1,000. For each one I ask a single question: would I want this exact URL as a search result?

If not, the reason Google gives barely matters. If yes, open it in URL Inspection, which shows the live status, the canonical you declared, and the canonical Google picked.

I do it in that order because the reason names are easy to misread. "Duplicate without user-selected canonical" sounds like a fault, but Google calls it working as intended when the URL it chose is the right one. "Crawled - currently not indexed" sounds final, but Google says it may index the page later and that you don't need to resubmit.

What each reason usually holds on a blog

Reason names are the ones in the report as of October 2026. The middle column is my summary of where these come from on blogs. The last column follows Google's documentation for each reason.

Reason	Typical blog URLs	Act?
Page with redirect	`http://` and `www` variants, old slugs, the platform subdomain you used before a custom domain	No, unless a current post URL is redirecting. Check the target is indexed.
Alternate page with proper canonical tag	Tracking parameters, trailing-slash and case variants that canonicalize to the clean URL	No. Google says no action is needed.
Duplicate without user-selected canonical	Duplicate URLs that declare no canonical	Only if Google picked the wrong URL. Then declare the canonical.
Duplicate, Google chose different canonical than user	A canonical pointing at a page with different content, near-identical posts, a cross-posted copy Google treats as the original	Yes. Compare both canonicals in URL Inspection.
URL marked 'noindex'	Feeds, search results, tag pages you chose to hide, drafts and previews	Only if a post is in the list.
URL blocked by robots.txt	Admin paths, internal search	Only if a post is in the list. robots.txt doesn't keep a URL out of search; noindex does.
Not found (404)	Deleted posts, mistyped inbound links, old URLs from a migration	301 it if the content moved. A removed post with no replacement can stay 404.
Soft 404	Empty tag pages, archive pages past the last post, an error page served with 200	Yes. Return a real 404 or put real content there.
Server error (5xx), Redirect error	Outages, redirect loops, chains from more than one migration	Yes, before anything else.
Crawled - currently not indexed	Thin tag and archive pages, sometimes posts	Only for posts you care about.
Discovered - currently not indexed	New posts, deep archive pages	Usually wait. Google gives no specific fix.

Predict the row before Google recrawls

You don't have to wait for a recrawl to know where a URL will land. The status code, the Location header, X-Robots-Tag, the canonical link and the robots meta tag decide most of it. This prints all five for one URL:

curl -sS -D - -o page.html "https://example.com/blog/my-post?utm_source=x" \
  | grep -iE '^(HTTP|location|x-robots-tag)'
grep -oiE '<link[^>]*rel="?canonical[^>]*>|<meta[^>]*name="?robots[^>]*>' page.html

I ran it against the blog on JustBlogged, the platform I build, on 17 October 2026. It lives at /blog on the main domain:

URL requested	Response	Expected row
`http://justblogged.com/blog/blog-404-page`	301 to `https://`	Page with redirect
`https://www.justblogged.com/blog/blog-404-page`	301 to the apex	Page with redirect
`/blog/blog-404-page/`	200, canonical without the slash	Alternate page with proper canonical tag
`/blog/blog-404-page?utm_source=x`	200, canonical to the clean URL	Alternate page with proper canonical tag
`/blog/BLOG-404-PAGE`	200, canonical to lowercase	Alternate page with proper canonical tag
`/blog/rss.xml`	200, `X-Robots-Tag: noindex, follow`	URL marked 'noindex'
`/blog/search?q=dns`	200, `X-Robots-Tag: noindex, follow`	URL marked 'noindex'
`/blog/tags/dns` (tag is "DNS")	404	Not found (404)

The last row is one I didn't expect. Post slugs are case-insensitive and canonicalize to lowercase, but tag URLs are case-sensitive, so /blog/tags/DNS is 200 and /blog/tags/dns is 404. Any site linking to a tag with the wrong case shows up under Not found. Worth checking on whatever platform you're on, since slugs and tags are often handled by different routes.

robots.txt under /blog does nothing

This one catches a lot of blogs that live under a path. That blog serves a file at /blog/robots.txt, but Google's robots.txt documentation says crawlers only read the file at the top level of the host. Anything under /blog is governed by the root robots.txt, and a rule in the blog's own file has no effect on Google.

So the noindex header is what keeps /blog/search out. The root file doesn't block it, Googlebot fetches it, reads the header, and files it under "URL marked 'noindex'". If you block it in robots.txt instead, Google's canonicalization guide warns it can still be indexed without its content, which is the "Indexed, though blocked by robots.txt" warning.

Platform defaults matter here too. WordPress sites created on 6.4 or later have attachment pages disabled and redirect them, so they show under Page with redirect. A site upgraded from an older version keeps them on, and they can turn up as indexable URLs.

The order I fix rows that hold posts

Server errors and redirect errors. Google can't evaluate a page it can't fetch, and an outage or loop usually hits every post at once.
Posts under "URL marked 'noindex'". Usually a leftover staging setting, a theme option, or a per-post SEO toggle. Remove it, then inspect the live URL.
Soft 404s. Real 404 for pages that are gone, real content for pages thin enough to look like errors.
"Duplicate, Google chose different canonical than user". Google won't pick a declared canonical that isn't similar to the page, so check the target has the same content. Cross-posted copies on Medium, DEV or Hashnode are the usual suspect when the canonical tag on the copy is missing.
Posts under "Crawled - currently not indexed". No fix attached. What you control is whether the post adds something your other posts don't, and whether your own posts link to it. Resubmitting it every day doesn't help.

Once every example URL under a reason is fixed, click Validate Fix on that reason. Google says validation typically takes up to about two weeks, and not to click it again until it has passed or failed.

If you moved hosts recently, most of the 404 and redirect rows are probably old URLs, and the migration redirects are the thing to fix before the report itself

Google Shows the Wrong Site Name for Your Blog: Where It Comes From and How to Fix It

Usama Ejaz — Fri, 16 Oct 2026 06:19:32 +0000

Google picks the site name it shows above your blog's results by itself. It reads your home page, and the strongest preference you can state there is the name in WebSite structured data. It also looks at og:site_name, the <title>, headings and other text on the home page, according to Google's site names documentation (last updated 10 December 2025). When Google shows the wrong name, the fix is to make those signals agree, add fallbacks in alternateName, and get the home page recrawled.

Two cases have no markup fix. Google only supports site names for a domain or subdomain, so a blog at example.com/blog can't get a name of its own. And Google can still decline a name it finds generic or already used by another site. The rest of this post covers how to see what your home page actually sends, what four platforms put there by default, and the fix for each wrong name you might be seeing.

The markup Google asks for

Google wants one WebSite object on the root URL of the domain or subdomain, with a name and the canonical home page url. It doesn't need to be on every page. alternateName is optional and takes a list in order of preference. Google's documentation suggests ending that list with your domain in lowercase, because it will strongly consider that as a backup when your preferred name isn't picked.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Field Notes",
  "alternateName": ["Field Notes Blog", "fieldnotes.dev"],
  "url": "https://fieldnotes.dev/"
}
</script>

If your platform already prints a WebSite block, change that block instead of pasting a second one into a custom head field. Google asks you to keep the site name properties in the same node and to avoid an additional WebSite block on the home page. The Rich Results Test doesn't cover site names, so check the syntax with the Schema Markup Validator instead.

This post is only about the home page, not the markup on individual posts.

Check what your home page sends to Googlebot

Viewing the source in your browser isn't always enough. On 16 October 2026 I requested the home pages of two Substack publications, on.substack.com and lennysnewsletter.com, twice each. With a Chrome user agent, the HTML had no JSON-LD at all. With Googlebot's user agent, the response was several times larger and contained a WebSite block with the publication name. Neither response had og:site_name.

So check the version Google receives. The URL Inspection tool in Search Console shows the HTML Google crawled; Google's help page for the tool explains the live test. For a quick look from a terminal, this fetches the home page with a Googlebot user agent and prints the title, og:site_name and the start of any WebSite block. The tr step flattens the HTML so JSON-LD spread over several lines still matches.

curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ \
  | tr -s '\n\t ' ' ' \
  | grep -oE '<title[^>]*>[^<]*|og:site_name"[^>]*|"@type" ?: ?"WebSite"[^}]{0,200}'

Some hosts answer scripted requests with a bot challenge instead of the page. Bear Blog and Medium returned Cloudflare challenge pages to my requests, and one Hashnode blog returned a Vercel security checkpoint. URL Inspection is the reliable check in that case.

What four platforms put on a blog's home page

I checked live home pages on 16 October 2026. Each row describes what the sites I sampled sent, which is the platform default unless the owner changed it.

Platform	Sites checked	Home page markup	Where to change the name
Ghost	`demo.ghost.io`, `platformer.news`	`WebSite` with the site title as `name`, plus matching `og:site_name`	The site title. No `alternateName` in the default output.
Substack	`on.substack.com`, `lennysnewsletter.com`	`WebSite` with the publication name, only in the Googlebot response. Title reads "Name	Substack". No `og:site_name`.
Hashnode	`townhall.hashnode.com`, `blog.greenroots.info`	`Blog`, not `WebSite`, with the full blog title as `name`; the same text in `og:site_name` and `<title>`	The blog title.
WordPress	`yoast.com`, `longreads.com`, `themeshaper.com`, `ma.tt`	yoast.com and longreads.com had a `WebSite` node. ThemeShaper and ma.tt had `og:site_name` but no `WebSite` node. WordPress core doesn't print JSON-LD itself, so the node depends on a plugin or theme.	With Yoast SEO: Settings, then Site basics, which has Website name and Alternate website name fields.

Hashnode's choice of Blog is a valid schema.org type, but Google's guide only describes WebSite, and it doesn't say whether a Blog node's name is read as a site name preference. On those blogs the title and og:site_name carry the same text, so the signals at least agree. Long titles like "GreenRoots Blog - A Blog by Tapas Adhikary" are what Google warns may be truncated on some devices.

Match the wrong name to its cause

The name Google shows usually tells you which rule you've run into.

Google shows your domain instead of a name

This is Google's fallback when it isn't confident in the name you gave. Confirm there is a WebSite block on the root URL and that it validates. Then make the visible home page agree with it: if the structured data says "Field Notes" and the title says "Home | My Blog", you're sending two answers. Add a shorter or more specific alternateName. A name that describes a category rather than a publication, like "Tech Blog", is one Google says it is unlikely to pick.

Google still shows the old name after a rename

The site name comes from the home page, so nothing changes until Google recrawls it. Request indexing for the home page in URL Inspection. Google's guide says crawling can take from several days to several weeks, and internal pages pick up the new name only after they are recrawled too. If you changed domains at the same time, the redirects and the Change of Address tool have to be done first.

A subdomain blog shows your main site's name

Google says that when a subdomain's home page has no structured data, the domain-level site name may be used as a fallback. If blog.example.com should carry its own name, its root URL needs its own WebSite block. If showing the company name is fine with you, there is nothing to fix.

A blog at /blog shows the main site's name

This is the subdirectory rule, and markup won't change it. Google's own example marks https://example.com/news as unsupported. My own product blog is in that position: it lives under /blog on the main domain, its home page prints a valid WebSite block with its own name, and under Google's rules that block can't give it a name separate from the one Google uses for the domain. For most company blogs that's the right result. If a separate name matters more than sharing the main domain, the blog has to move to a subdomain.

The name differs between www and the apex, or http and https

Google asks for the same structured data on every duplicate home page, and when a variant redirects, it uses the redirect target. If every variant of your address redirects to one home page, there is nothing to align. A missing redirect leaves two home pages that each need the same markup. Pick one and redirect the other.

Google shows an acronym or a different form of your name

Google says it may choose an acronym when the site is better known by one, and it generally won't give the same name to two sites that are global in nature. List the forms you're willing to accept in alternateName, most preferred first. As a last resort, Google's documentation says you can set the lowercase domain itself as name, and it will generally select that.

I checked all of this while wiring the WebSite block into the themes on JustBlogged. The Substack result surprised me the most... the markup only shows up when you ask as Googlebot, so a view-source check says it isn't there

Mixed Content After Moving a Blog to HTTPS: Which http:// Images Still Load

Usama Ejaz — Fri, 16 Oct 2026 06:19:31 +0000

Once a blog is on HTTPS, every image, script, stylesheet and iframe its pages still load over http:// is mixed content, and current browsers no longer handle it one way. A plain <img src="http://..."> is rewritten to https:// and loads, but only if the image host answers on HTTPS; there is no fallback to the old address. Scripts, stylesheets and iframes are blocked. Responsive images are blocked too: any http:// URL inside srcset or a <picture> source stops the image from rendering, even when the same tag's src is already https://.

That last case is easy to miss after a migration, because a find-and-replace aimed at src="http:// or a quick look at the post's main image catches the src and leaves the srcset. Below is what I measured in Chromium, why the spec treats responsive images differently, a script that lists every http:// subresource on a live blog, and the order I'd fix them in.

What Chromium 141 did with each http:// reference

On October 15, 2026 I ran a headless Chromium 141.0.7390.37 (through Playwright 1.56.1) against a test page served over HTTPS. The page pulled resources from two local hosts on the standard ports: one that served every file over both HTTP and HTTPS, and one that only spoke HTTP, the way an old personal image server or a lapsed CDN might. The server log recorded which scheme each request actually arrived on, and the page reported whether each image decoded. I ran the same page a second time with an upgrade-insecure-requests meta tag in the head.

Reference in the HTML	Default behavior	With `upgrade-insecure-requests`
`<img src="http://...">`, host also serves HTTPS	Upgraded to https, loads	Upgraded, loads
`<img src="http://...">`, host is HTTP only	Upgraded, connection refused, broken image	Same: broken image
`<img srcset="http://... 1x">`	Blocked	Upgraded, loads
`<img src="https://..." srcset="http://... 300w, http://... 1024w">`	Blocked; the browser picked a srcset candidate and never used the https `src`	Upgraded, loads
`<picture><source srcset="http://...">`	Blocked; the fallback `<img>` was not used	Upgraded, loads
Inline `style="background-image:url(http://...)"`	Upgraded, loads	Upgraded, loads
`<link rel="stylesheet" href="http://...">`	Blocked	Upgraded, applied
`<script src="http://...">`	Blocked	Upgraded, ran
`<iframe src="http://...">`	Blocked	Upgraded, loads

The console messages match the two outcomes. An upgraded image logs a warning ending in "This request was automatically upgraded to HTTPS", and a blocked one logs an error ending in "This request has been blocked; the content must be served over HTTPS." If you open DevTools on a migrated post and see only warnings, the page is relying on the upgrade, and each of those images depends on its host keeping HTTPS working.

Why a responsive image breaks when its plain src would have loaded

The automatic upgrade comes from the W3C Mixed Content Level 2 draft. It upgrades requests whose destination is an image, audio or video, then lists an exception: a request whose destination is "image" and whose initiator is "imageset" is left alone, and the spec gives the reason as "for historical reasons". Requests that aren't upgraded are blocked. MDN's mixed content reference spells out the practical meaning: an <img> set through src is upgradable, while one set "via srcset or <picture>" is blockable.

All three engines now apply the upgrade to plain images. Chrome announced the plan in 2019, and its update on that post says mixed images are "autoupgraded and blocked if they fail to load over https://". Firefox followed in version 127, where images, audio and video "are not loaded if they are unavailable via HTTPS". WebKit's Safari 18.0 notes say images and media "will now be auto-upgraded to HTTPS, in adherence with Mixed Content Level 2". I only ran Chromium, so the srcset result above is measured in the engine behind Chrome and Edge, and for Firefox and Safari it follows from the spec rather than from my test.

The practical consequence is that the scheme in srcset decides the image. A browser that chooses a candidate from srcset doesn't go back to src when that candidate is blocked, which is why the row with an https src still rendered as a broken image.

List every http:// subresource on the live blog

Checking posts one at a time in DevTools doesn't scale to an archive of a few hundred. The script below reads your sitemap, parses each page, and prints every http:// subresource with the outcome the table predicts. For references a browser would upgrade, it also requests the https:// version, so an image that will break is labelled BROKEN before a reader finds it. It uses only the Python standard library.

#!/usr/bin/env python3
"""Find http:// subresources on an HTTPS blog and predict what browsers do with each.
Usage: python3 mixed_content_scan.py https://example.com/sitemap.xml  (or page URLs)"""
import re, sys, ipaddress, urllib.request
from html.parser import HTMLParser
from urllib.parse import urlsplit

UA = {"User-Agent": "mixed-content-scan/1.0"}

def get(url):
    with urllib.request.urlopen(urllib.request.Request(url, headers=UA), timeout=20) as r:
        return r.read().decode("utf-8", "replace")

def https_ok(url):
    u = "https://" + url[len("http://"):]
    try:
        with urllib.request.urlopen(urllib.request.Request(u, headers=UA), timeout=10) as r:
            return r.status < 400
    except Exception:
        return False

def is_ip(url):
    try:
        ipaddress.ip_address(urlsplit(url).hostname or "")
        return True
    except ValueError:
        return False

CSS_URL = re.compile(r"url\(\s*['\"]?(http://[^'\")\s]+)", re.I)

class Scan(HTMLParser):
    def __init__(self):
        super().__init__()
        self.found, self.in_picture, self.in_style = [], False, False
    def add(self, where, url, kind):
        self.found.append((where, url, kind))
    def handle_starttag(self, tag, attrs):
        a = dict(attrs)
        if tag == "picture": self.in_picture = True
        if tag == "style": self.in_style = True
        for part in (a.get("srcset") or "").split(","):
            u = part.strip().split(" ")[0]
            if u.startswith("http://"): self.add(f"<{tag} srcset>", u, "blocked")
        src = a.get("src") or ""
        if src.startswith("http://"):
            if tag == "source" and self.in_picture: self.add("<picture><source src>", src, "blocked")
            elif tag in ("img", "audio", "video", "source"): self.add(f"<{tag} src>", src, "upgraded")
            else: self.add(f"<{tag} src>", src, "blocked")
        if tag == "video" and (a.get("poster") or "").startswith("http://"):
            self.add("<video poster>", a["poster"], "upgraded")
        if tag == "link" and "stylesheet" in (a.get("rel") or "") and (a.get("href") or "").startswith("http://"):
            self.add("<link stylesheet>", a["href"], "blocked")
        for u in CSS_URL.findall(a.get("style") or ""):
            self.add("inline style url()", u, "upgraded")
    def handle_endtag(self, tag):
        if tag == "picture": self.in_picture = False
        if tag == "style": self.in_style = False
    def handle_data(self, data):
        if self.in_style:
            for u in CSS_URL.findall(data): self.add("<style> url()", u, "upgraded (blocked if a font)")

def pages(arg):
    if arg.endswith(".xml"):
        locs = re.findall(r"<loc>\s*([^<\s]+)\s*</loc>", get(arg))
        out = []
        for l in locs:
            out += pages(l) if l.endswith(".xml") else [l]
        return out
    return [arg]

def main():
    urls = [p for a in sys.argv[1:] for p in pages(a)]
    total, checked = 0, {}
    for page in urls:
        try:
            s = Scan(); s.feed(get(page))
        except Exception as e:
            print(f"ERROR  {page}  {e}"); continue
        for where, u, kind in s.found:
            total += 1
            if kind.startswith("upgraded"):
                if is_ip(u): kind = "blocked (IP address host)"
                else:
                    if u not in checked: checked[u] = https_ok(u)
                    if not checked[u]: kind = "upgraded, but https copy fails: BROKEN"
            print(f"{kind:40} {where:22} {u}  on {page}")
    print(f"\n{len(urls)} pages scanned, {total} http:// subresources found")

if __name__ == "__main__":
    main()

Run it with your sitemap or with individual post URLs:

python3 mixed_content_scan.py https://example.com/sitemap.xml

It prints one line per reference. With illustrative URLs, the output looks like this:

blocked                                  <img srcset>           http://old.example.com/wp-content/uploads/hero-1024x576.jpg  on https://example.com/hello-world
upgraded, but https copy fails: BROKEN   <img src>              http://photos.example.net/2014/cat.jpg  on https://example.com/my-cat

I checked the classifications against the Chromium test page above, then ran it over the 48 URLs in my own blog's sitemap, which returned no http:// subresources. It reads the HTML the server sends, so it won't see URLs inside external stylesheets or markup that JavaScript inserts after load, and it marks every url() inside a <style> block as an image even though a font loaded that way is blocked. Those gaps are small on most blogs, but if a theme uses custom fonts from an old host, open one page in DevTools as well.

Fix each reference at its source, by the kind of host

The script's output falls into four groups, and each has a different fix. References to your own old address are absolute http://yourdomain.com/... URLs written into posts before the site had HTTPS. Rewrite them to https:// in the content itself. On a WordPress install, WP-CLI's search-replace handles serialized data, and its documented examples skip the guid column. Run it with --dry-run first:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

If you're leaving WordPress, do the same replacement in the export file before importing it anywhere, so the new platform never stores the old scheme.

Third-party hosts that answer on HTTPS only need the scheme changed. The upgrade already loads them, but editing the URL removes the dependency on browser behavior, and it fixes the copy of your post that RSS readers and scrapers receive.

Hosts with no working HTTPS are where readers already see broken images. Download the files while the HTTP address still answers and serve them from your own blog, then point every reference at the new copy. If the HTTP address is already gone, the image has to come from a backup or the Wayback Machine.

Scripts and iframes are usually old embed codes and widgets. A blocked http:// embed is often a service that has since moved to HTTPS under a new snippet, so replace the snippet rather than editing the scheme.

Add upgrade-insecure-requests after the rewrite

The upgrade-insecure-requests directive tells the browser to rewrite every non-navigational http:// request to https:// before sending it. In the test, it rescued every blocked row: srcset images, the picture source, the stylesheet, the script and the iframe. It can be sent as a response header or placed in the page head:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

It works as a safety net for references the rewrite missed. It can't fix a host without HTTPS, which failed in both runs, and MDN notes there's no fallback to HTTP. It also only affects browsers loading your pages, so the http:// URLs remain in your stored content and in your feed. The upgraded script row shows the other reason to keep it as a backstop: a script you would have noticed as blocked now runs silently from whatever currently answers at that address.

On a host where you control headers, send it as a header instead so it covers every response.

I went down this path while moving old posts onto custom domains for JustBlogged. The srcset row is the one I didn't expect... a find-and-replace on src looks done, and the image still doesn't render

DNSSEC When Moving a Blog's DNS: Remove the DS Record Before the Nameservers Change

Usama Ejaz — Wed, 14 Oct 2026 05:51:27 +0000

DNSSEC can only break a blog migration at one moment: when the domain's nameservers change. Everything else about a host move leaves it alone.

Here is the failure. Your registrar holds a DS record that tells validating resolvers which key should be signing your zone. Move the zone to a new DNS provider while that DS record still describes the old provider's key, and resolvers like 1.1.1.1, 8.8.8.8 and Quad9 answer with SERVFAIL instead of an IP address. The blog disappears for anyone behind a validating resolver and keeps working for everyone else. So it can look fine on your laptop and be down for half your readers, which is the worst kind of outage to debug.

The safe order is short: remove the DS record at the registrar, wait out its TTL, change the nameservers, then turn on DNSSEC at the new provider and add its DS record. The rest of this post is how to tell whether it applies to you, three queries that show the state of the chain with nothing but curl, and what to do if you already switched and things broke.

A normal host move doesn't touch DNSSEC

Most host moves are an edit inside your existing zone: a new A record for the apex, a new CNAME for www. The provider that signs your zone signs the edited records too, and the DS record at the registrar still matches because the keys didn't change.

DNSSEC becomes your problem when the nameservers change. That covers moving DNS to Cloudflare or Route 53, switching from your registrar's default nameservers to custom ones, going back the other way, and transferring the domain to a registrar whose DNS you'll use instead. In every one of those, the party signing the zone changes while the DS record at the registry stays where it was.

Check the chain with three queries

Google Public DNS and Cloudflare's 1.1.1.1 both answer DNS queries as JSON over HTTPS. Google's JSON API takes cd=1 to disable DNSSEC validation, and Cloudflare's takes the same parameter. Comparing a normal answer with a cd=1 answer tells you whether DNSSEC is the reason a name doesn't resolve.

# 1. Is there a DS record at the registry?
curl -s 'https://dns.google/resolve?name=example.com&type=DS'

# 2. Does the name resolve with validation on?
curl -s 'https://dns.google/resolve?name=example.com&type=A'

# 3. Does it resolve with validation off?
curl -s 'https://dns.google/resolve?name=example.com&type=A&cd=1'

I ran queries 2 and 3 on October 14, 2026 against dnssec-failed.org, a test domain whose DS record deliberately doesn't match the keys its nameservers publish. With validation on, Google returned:

{"Status":2, "AD":false, "CD":false,
 "Comment":"DNSSEC validation failure. Check http://dnsviz.net/d/dnssec-failed.org/dnssec/ ...",
 "extended_dns_errors":[{"info_code":9,"extra_text":"No DNSKEY matches DS RRs of dnssec-failed.org"}]}

With cd=1, the same resolver returned "Status":0 and the A record 96.99.227.255. Cloudflare gave the same pair through https://cloudflare-dns.com/dns-query (send the header accept: application/dns-json), with the reason in its Comment field as EDE(9): DNSKEY Missing. The records exist and the nameservers answer. Validation is the only thing stopping resolution.

DS query	Query 2	Query 3 (cd=1)	What it means
No answer	Status 0	Status 0	DNSSEC is off at the registry. A nameserver change won't trip on it.
Answer present	Status 0, `"AD":true`	Status 0	The chain validates. Remove the DS record before you change nameservers.
Answer present	Status 2 (SERVFAIL)	Status 0 with an answer	The chain is broken. Fix the DS record, not your A or CNAME records.
Either	Status 2	Status 2	Something other than DNSSEC is failing, usually nameservers that don't answer for the zone.

The extended error code narrows it down further. RFC 8914 defines code 9, DNSKEY Missing, as "A DS record existed at a parent, but no supported matching DNSKEY record could be found for the child". That is exactly what a DS record left over from the old provider produces. Code 10, RRSIGs Missing, means signatures were expected and none came back, which fits a new provider that isn't signing the zone yet. Cloudflare lists the codes 1.1.1.1 returns on its Extended DNS Error codes page. If you want a picture of the whole chain, DNSViz and Verisign's DNSSEC Analyzer both take a domain and show where it breaks.

Look at the TTL on the DS answer too, because it decides how long the move takes. On the same day, the DS record for cloudflare.com came back from 1.1.1.1 with a TTL of 86400 seconds (one day) and from Google with 7212, which is just the time left in Google's cache. A fresh answer shows the registry's full value. A cached one shows what remains.

The order that works when DNS moves to a new provider

Cloudflare's DNSSEC docs and Route 53's guide to migrating a domain that's in use describe the same sequence. Route 53 states the constraint plainly: "You can't have DNSSEC signing enabled across two providers at the same time."

Recreate every record at the new provider: the blog's A and CNAME records, MX for email, and any TXT verification records. Leave DNSSEC off there for now.
Remove the DS record at your registrar, and leave signing on at the old provider. Route 53's disable procedure warns that "some registrars have scheduled DS removal, for example once a day", so confirm it's gone by asking the registry's own nameserver, for example dig +norec DS example.com @a.gtld-servers.net for a .com.
Wait out the DS TTL. Cloudflare says it is commonly 24 to 48 hours for most TLDs, and its troubleshooting page says to wait at least 1.5 times the TTL: "If the DS TTL is 24 hours, wait 36 hours."
Change the nameservers at the registrar and wait for the old NS TTL. Route 53 notes the NS record's typical TTL is two days unless you lowered it beforehand.
Turn on DNSSEC at the new provider and add its DS record at the registrar. Cloudflare Registrar adds the DS record itself, which "can take one to two days", and registrars that read CDS records can pick it up automatically. Everywhere else you paste the key tag, algorithm, digest type and digest by hand.
Run the three queries again. Query 2 should now come back with "AD":true.

Between steps 2 and 5 the domain resolves without DNSSEC protection. RFC 6781 calls that window "the only viable operation" when the old and new providers don't cooperate. The way around it is multi-signer DNSSEC from RFC 8901, where both providers' keys are published during the move. Cloudflare supports it as an active migration, but only if the old provider lets you add DNSKEY records at the zone apex. I think for a blog that's overkill... I'd take the unsigned day or two over coordinating key imports between two DNS companies, unless the old provider already documents multi-signer support.

What registrars do on their own when you change nameservers

Some registrars handle part of this for you, and their help pages differ in ways that matter mid-move. These are from each registrar's docs as of October 14, 2026.

Registrar	Documented behavior
Squarespace Domains	DNSSEC is "automatically enabled" on supported TLDs and "automatically disabled if you switch to using custom nameservers" (source). You can add one DS record for custom nameservers.
Namecheap	Automatic on BasicDNS and PremiumDNS (source). With custom DNS you manage DS records yourself, and turning DNSSEC back on re-activates "the records you previously configured" (source).
Porkbun	Recommends deleting DNSSEC records before transferring a domain in, then turning on Porkbun's DNSSEC or adding your own afterward (source).
Cloudflare Registrar	Publishes the DS record automatically from the zone's CDS records. "There is currently no way to manually control the exact timing of DS publication" (source).

Namecheap is the one that bites. Switch to custom nameservers, re-enable DNSSEC, and the old DS values come back, describing keys the new provider doesn't have. Replace them with the new provider's values before you save. Squarespace disables DNSSEC as part of the nameserver change itself, so a resolver that cached the DS record earlier can still fail until that cache expires. If your registrar lets you remove the DS record as a separate step, do it a day or two ahead.

Already switched and getting SERVFAIL

Go to the registrar and either delete the DS record or replace it with the one your new provider shows. Deleting is quicker to get right, and you can add the new DS record once the domain resolves. Google's troubleshooting page gives the same fix: "ask your domain registrar to remove stale DS records."

Resolvers that cached the old DS record keep failing until its TTL runs out, so some readers can see the error for up to a day after the fix. Cloudflare's purge cache tool and Google's flush cache page each clear one resolver's cache for a name you enter. That helps readers on those two resolvers and does nothing for an ISP's resolver. Don't touch your A and CNAME records while you wait. They aren't the problem, and editing them adds a second unknown.

A broken chain also stops your new host from getting a certificate. Under CA/Browser Forum ballot SC-085v2, CAs have had to validate DNSSEC on CAA lookups since March 15, 2026, and the Baseline Requirements say a validation error such as SERVFAIL "MUST NOT be treated as permission to issue." So a host that issues HTTPS automatically can sit at "pending" until the DS record is fixed, with no useful error. I wrote up the rest of that lookup in CAA records and your blog host.

I went through all of this while wiring custom domains on JustBlogged. If a domain is stuck on "pending" after a nameserver change, those three queries tell you in a minute whether DNSSEC is the reason