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):

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

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:

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

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.

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:

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

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.

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.

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

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.

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

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.

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:

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

1. 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.
2. 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.
3. Soft 404s. Real 404 for pages that are gone, real content for pages thin enough to look like errors.
4. "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.
5. 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

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.

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

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.

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

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.

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."

1. 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.
2. 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.
3. 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."
4. 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.
5. 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.
6. 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.

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

This post walks through that flow using a live remote MCP server I run at https://justblogged.com/mcp as the example. Every response below is real output from curl, trimmed to the relevant parts. The rules come from the MCP authorization specification.

Step 1: The unauthenticated request

Some MCP methods are public on this server. initialize and tools/list work without a token, so a client or a curious developer can see what the server does before signing in. Calling a tool that touches blog data is different:

curl -i -X POST https://justblogged.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_blogs","arguments":{}}}'

HTTP/2 401
cache-control: no-store
www-authenticate: Bearer realm="OAuth", resource_metadata="https://justblogged.com/.well-known/oauth-protected-resource/mcp", scope="blogs:manage"

The WWW-Authenticate header is the starting point for everything else. It tells the client three things:

• Bearer: send an access token in the Authorization header.
• resource_metadata: where to find metadata about this protected resource. This comes from RFC 9728.
• scope: which scope to ask for. Here there is only one, blogs:manage.

A client that gets this response does not need any server-specific configuration. It has a URL to follow.

Step 2: Protected resource metadata

curl https://justblogged.com/.well-known/oauth-protected-resource/mcp

{
  "resource": "https://justblogged.com/mcp",
  "authorization_servers": ["https://justblogged.com"],
  "scopes_supported": ["blogs:manage"],
  "bearer_methods_supported": ["header"],
}

This document answers "who issues tokens for this server?" The MCP server is the resource server. The authorization server could be a separate service like an identity provider, and authorization_servers is how the client finds it. In this case both live on the same origin.

The path matters. The metadata URL is the well-known prefix plus the path of the MCP endpoint (/mcp), which is how a host serving several protected resources can describe each one separately. The spec says clients should use the URL from WWW-Authenticate when it is present, and fall back to constructing the well-known URI when it is not.

resource is also used later. The client sends it as the resource parameter (RFC 8707, Resource Indicators) in the authorization and token requests, so the token is issued for this specific server and is not meant to be accepted anywhere else.

Step 3: Authorization server metadata

Next, the client fetches the authorization server's metadata (RFC 8414):

curl https://justblogged.com/.well-known/oauth-authorization-server

{
  "issuer": "https://justblogged.com",
  "authorization_endpoint": "https://justblogged.com/oauth/authorize",
  "token_endpoint": "https://justblogged.com/oauth/token",
  "registration_endpoint": "https://justblogged.com/oauth/register",
  "scopes_supported": ["blogs:manage"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post", "none"],
  "code_challenge_methods_supported": ["S256"],
  "authorization_response_iss_parameter_supported": true,
  "client_id_metadata_document_supported": true
}

The fields a client reads here:

• authorization_endpoint and token_endpoint: where to send the user, and where to exchange the code.
• code_challenge_methods_supported: ["S256"]: PKCE is supported, with SHA-256. The MCP spec requires clients to check this and refuse to continue if PKCE is not advertised.
• token_endpoint_auth_methods_supported includes none: public clients, such as a desktop app or CLI that cannot keep a secret, are allowed.
• registration_endpoint and client_id_metadata_document_supported: the two ways a client can get a client ID. More on that next.

This server does not serve /.well-known/openid-configuration (it returns 404). That is fine. The spec has clients try both OAuth and OpenID Connect discovery URLs, and either one is enough.

Step 4: Getting a client ID

Classic OAuth assumes a developer registers their app with the provider ahead of time. That does not work for MCP, where any client might connect to any server. The spec offers two answers.

Dynamic client registration

With Dynamic Client Registration (RFC 7591), the client registers itself at runtime:

curl -X POST https://justblogged.com/oauth/register \
  -H 'Content-Type: application/json' \
  -d '{
    "client_name": "curl-test",
    "redirect_uris": ["http://127.0.0.1:33418/callback"],
    "grant_types": ["authorization_code", "refresh_token"],
    "response_types": ["code"],
    "token_endpoint_auth_method": "none"
  }'

{
  "client_id": "x9FmJdo4leive3by",
  "redirect_uris": ["http://127.0.0.1:33418/callback"],
  "client_name": "curl-test",
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none",
  "client_id_issued_at": 1791646827
}

201 Created, and the client has an ID. The loopback redirect URI is typical for CLI tools, which start a small local server to receive the code. The downside of this approach is that the server ends up with a registration for every client instance, and it knows nothing about who is behind a client_name beyond what the client claims.

Client ID Metadata Documents

The newer option, added in the 2025-11-25 revision of the spec, is a Client ID Metadata Document. Instead of registering, the client uses an HTTPS URL as its client_id. That URL serves a JSON document with the client's name and redirect URIs. The authorization server fetches it when the user arrives, and checks that the redirect URI in the request is listed there.

This ties a client ID to a domain the client's developer controls, and there is no registration table to grow. The metadata advertises client_id_metadata_document_supported: true, so clients that support it can use it, and clients that only know registration still have /oauth/register.

Step 5: Authorization with PKCE

Now the client sends the user to the browser. First it creates a PKCE pair:

verifier=$(openssl rand -base64 48 | tr -d '=+/' | cut -c1-64)
challenge=$(printf '%s' "$verifier" | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '=')

Then it opens a URL like this:

https://justblogged.com/oauth/authorize
  ?response_type=code
  &client_id=x9FmJdo4leive3by
  &redirect_uri=http://127.0.0.1:33418/callback
  &scope=blogs:manage
  &state=<random>
  &code_challenge=<challenge>
  &code_challenge_method=S256
  &resource=https://justblogged.com/mcp

The user logs in, sees a consent screen that says the client can read and manage blog content, settings, domains and themes, and approves. The browser is redirected to the loopback address with a code, the state value, and an iss parameter (the metadata says authorization_response_iss_parameter_supported), which lets the client confirm the response came from the server it started with.

PKCE is what makes this safe for a public client. The code alone is useless. Only the party holding the original verifier can exchange it, so a code intercepted on the way back cannot be redeemed by someone else.

Step 6: The token

The client exchanges the code at the token endpoint:

curl -X POST https://justblogged.com/oauth/token \
  -d grant_type=authorization_code \
  -d code=<code> \
  -d redirect_uri=http://127.0.0.1:33418/callback \
  -d client_id=x9FmJdo4leive3by \
  -d code_verifier="$verifier" \
  -d resource=https://justblogged.com/mcp

The response contains an access token and, because refresh_token is a supported grant, a refresh token. From then on every MCP request carries:

Authorization: Bearer <access_token>

The metadata lists header as the only bearer method, which matches the spec: tokens go in the header, never in the URL. When the access token expires, the client uses the refresh token to get a new one without sending the user back to the browser. Clients like Claude Code store and refresh tokens on their own, which is why you sign in once.

If a token is wrong or unknown, the server rejects it. For example, a token request with a client ID that does not exist returns:

{"error":"invalid_client","error_description":"Client not found"}

The scope, and its tradeoff

blogs:manage is the only scope. A token with it can do everything the signed-in account can do: list and read posts, publish, delete, change domains and edit themes, across every blog the account has access to. Normal account permissions still apply, so a member who cannot delete a blog in the dashboard cannot delete it over MCP either.

A single scope keeps the consent screen honest and simple, and it means every client gets the same capabilities. The cost is that there is no way to hand an agent read-only access, or write access to one blog and not the others. If you want an assistant to audit your archive, it gets the same token it would need to delete it.

Finer scopes, such as separate read and write, or scopes per blog, would fix that. For now, the practical move is to use clients you trust, keep work in draft, and ask the assistant to show destructive changes before running them.

Summary of the flow

1. Client calls the MCP endpoint and gets 401 with WWW-Authenticate.
2. Client reads the protected resource metadata from resource_metadata.
3. Client reads the authorization server metadata and checks for S256.
4. Client gets a client ID through registration or a metadata document URL.
5. User approves in the browser; the client receives a code.
6. Client exchanges the code plus PKCE verifier for tokens, bound to the resource.
7. Every MCP request carries Authorization: Bearer.

That is the whole handshake. The live responses above are from the JustBlogged MCP endpoint I used while building it.

The fix is to add one line, but you need two facts first: which CAA record actually applies to your blog's hostname, and which CA your host issues from. The second one is less obvious than it should be. Some hosts don't document their CA, and for one major host the docs and the certificates it actually issues disagree. I checked both, using live DNS queries and Certificate Transparency logs, on October 11, 2026.

Find the CAA record that applies to your blog's hostname

A CA doesn't just look at your apex domain. RFC 8659 has it start at the exact hostname on the certificate, follow any CNAME, and stop at the first CAA record set it finds. If there's nothing at that name, it moves up one label of your name and tries again. Let's Encrypt's CAA page gives the order for www.community.example.org as that name, then community.example.org, then example.org, "stopping at the first CAA record it finds".

For a blog, that leads to three different outcomes depending on how you connected the domain:

• An apex domain set up with A records has no CNAME to follow, so the CAA records on your own apex are the ones that count.
• A www or blog subdomain that CNAMEs to a host target which publishes its own CAA records gets the host's records. Yours are never reached, and you can't edit the host's.
• A subdomain that CNAMEs to a target with no CAA records sends the lookup back up your own tree, to example.com. The target's parent domain is never consulted.

That last case is easy to get wrong. www.taniarascia.com is a CNAME to tania.netlify.app, which has no CAA records. The parent zone netlify.app does have one, and it only allows DigiCert, through one specific account. Even so, Let's Encrypt issued a certificate for www.taniarascia.com on August 16, 2026, because the lookup went to taniarascia.com and not to netlify.app.

To see what a CA will see, query the exact hostname first and then each parent until something comes back:

dig CAA www.example.com +noall +answer
dig CAA example.com +noall +answer

If dig isn't installed, Google's public resolver answers the same question over HTTPS:

curl -s "https://dns.google/resolve?name=www.example.com&type=CAA"

An empty answer at every level means no CAA restriction applies, and any CA may issue. In that case CAA isn't the reason your certificate is stuck. If the record you find lists only CAs your host doesn't use, you've found the problem.

The certificate authority each blog host uses

The table combines each host's documentation with what I observed on October 11, 2026. "Target CAA" is what the host's CNAME target returned when I queried it. Where a host publishes CAA there, those records govern any subdomain you point at it, whatever your own zone says. The last column is the value I'd put in your own record for an apex domain, or for a subdomain whose target has no CAA.

Three rows need more explanation. WordPress.com's support page says its certificates come from Let's Encrypt, and its own error text reads "This domain has CAA DNS records that do not allow Let's Encrypt to issue a certificate." But the current certificates for the custom domains I looked up, including longreads.com, were issued by Google Trust Services in July and September 2026. Each of those certificates covers 42 or 43 names, including tls.automattic.com, which matches the batching the same support page describes. I found no current Let's Encrypt certificate for those names. Until the docs and the logs agree, allowing both letsencrypt.org and pki.goog is the record that works either way.

Substack doesn't document which CA it uses. Its custom-domain target has no CAA records, so the lookup comes back to your zone, and the Google Trust Services certificates on www.slowboring.com from August 2026 show which CA is in use for that domain now. The target resolves to Cloudflare addresses, which suggests it can switch among Cloudflare's CAs. That is an inference, and it's why I'd add letsencrypt.org too.

Ghost(Pro) is the case I can't resolve from public sources. A www subdomain is covered by the CAA on the ghost.io target, and the certificate on www.404media.co was issued by Certainly, Fastly's CA, in September 2026. For an apex on Ghost's A record, Ghost doesn't say which CA it uses, so the safe move is to ask Ghost support before restricting the apex, or to leave it unrestricted.

Write the CAA record

CAA authorizations are additive, so you add one issue line per CA and keep the CAs you already rely on for other names under the same domain. A zone with a WordPress.com blog at the apex, following the table above, would look like this:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "pki.goog"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

The iodef line is optional. It tells CAs where to report certificate requests that violate your policy. issuewild applies only to wildcard certificates, and when one is present, the issue lines are ignored for wildcards. Adding issuewild ";" blocks wildcards entirely. Before you add it, confirm that nothing in the zone, including a CDN in front of another site, relies on a wildcard certificate.

Records you place on a subdomain override the apex for that subdomain and everything below it. That's how you allow a host for blog.example.com without loosening the policy on example.com. The opposite also happens, and it's the usual way a stale record breaks a new host: a record added years ago at the apex for one CA now covers every subdomain that has no record of its own.

The accounturi parameter from RFC 8657 restricts issuance to one ACME account. Netlify publishes its Let's Encrypt account URI for exactly this use, and none of the other hosts in the table document one. An accounturi the CA doesn't recognize makes the line unsatisfiable, so only add one your host has published.

If you use Cloudflare DNS with Universal SSL turned on, Cloudflare adds CAA records automatically for its own CAs as soon as you add any CAA record to the zone. Those records don't appear in the dashboard. Check with dig to see the full set a CA receives.

When the CAA lookup itself fails

A correct record still won't help if CAs can't read it. Under the CA/Browser Forum Baseline Requirements, CAs have checked CAA from several network locations since 2025. Since March 15, 2026, they must also perform DNSSEC validation on CAA lookups, and a validation error such as SERVFAIL "MUST NOT be treated as permission to issue." A zone with broken DNSSEC, often left over from changing DNS providers without removing the old DS record at the registrar, can now block issuance even with no CAA record at all. If dig returns SERVFAIL for your CAA query, fix DNSSEC before changing any records.

Resolvers keep serving your old CAA record until its TTL runs out. Lower the TTL before you edit, then wait at least that long before you ask the host to retry the certificate.

When deleting the CAA record is the better fix

If nobody can say why a CAA record exists, deleting it is a legitimate answer. With no CAA anywhere in the tree, any public CA can issue for the name, which is the default for most domains. CAA earns its place when you've decided which CAs may issue for your domain and you watch the iodef reports or Certificate Transparency alerts. A record copied from an old tutorial and forgotten gives you none of that, and it will break the next host move.

I learned most of this while wiring custom domains on JustBlogged. Certificates there come from Let's Encrypt once DNS points at the host, so a restricted zone only needs letsencrypt.org allowed.

Reading data over MCP is easy. Writing to something that is public on the internet is where every small decision starts to matter. Below is what I decided, what I'm still unsure about, and what I'd do differently

Auth: OAuth instead of an API key in a config file

The first version of most MCP servers I looked at was an API key pasted into a JSON config. It works. It also means a long-lived secret with full account access sitting in a dotfile, often synced, sometimes committed

I went with what the MCP authorization spec describes: OAuth 2.1 with PKCE. The flow in practice:

1. The client calls a tool without a token and gets a 401 with a WWW-Authenticate header. That header carries resource_metadata (RFC 9728) and the scope to ask for

2. The client reads the protected resource metadata, finds the authorization server, then reads its metadata (RFC 8414)

3. It checks that code_challenge_methods_supported includes S256. The spec says a client should refuse to continue without PKCE

4. It gets a client ID, either by registering itself at runtime (Dynamic Client Registration, RFC 7591) or by using a Client ID Metadata Document URL, which the 2025-11-25 revision added

5. The browser opens, the user logs in and approves, and the code comes back to a loopback redirect like http://127.0.0.1:33418/callback

6. The client exchanges the code plus the PKCE verifier for an access token and a refresh token, with a resource parameter (RFC 8707) so the token is bound to this one server

From the user side that's "paste a URL, log in". No secret to copy anywhere

Dynamic registration has a cost I didn't think about at first. Every client instance registers, so the server ends up with a table of registrations and knows nothing about who is behind a given client_id. Metadata documents fix that by tying the client ID to a domain the client developer controls. I support both, because not every client does the newer one yet

Two smaller things that took me longer than they should have. The metadata URL is the well-known prefix plus the endpoint path (/.well-known/oauth-protected-resource/mcp), not just the root. And I left initialize and tools/list public on purpose, so anyone can see every tool schema before signing in. I think that's the right call for a write API... you should know what an agent will be able to do before you hand it a token

Scope design: one scope that covers delete

This is the part I'm least happy with

There is exactly one scope, blogs:manage. A token with it can do whatever the signed-in account can do, across every blog the account can manage: read, publish, delete posts, change domains, edit themes. Normal account permissions still apply, so a team member who can't delete a blog in the dashboard can't do it over MCP either

Why one scope. It keeps the consent screen honest and short, and every client gets the same capabilities, so I'm not debugging "works in Cursor, not in Claude" because of scope negotiation

The cost is real though. You can't give an agent read-only access to audit your archive. You can't give it write access to one blog and not the other three. If you want it to fix a typo, it gets the same token that can delete the blog

The obvious split is read vs write. I'm not sure that's enough. Fixing a typo in a draft and deleting a blog are both "write". Maybe it's read / write drafts / publish / destructive. Maybe it's per blog. And every extra scope is one more checkbox on a consent screen people click through without reading

Still not decided

Tool design and annotations

MCP tools can carry annotations like readOnlyHint, destructiveHint and idempotentHint. Clients use them to decide when to ask the user before running a call. They're hints, not enforcement, but a client that trusts them will auto-approve what you mark as safe

I got some of these wrong in the first version and had to go back through every tool. The questions I ended up asking per tool:

• Can this make something disappear or overwrite content someone can't get back? Then destructiveHint: true. Deletes obviously, but also some updates

• If the agent retries the same call with the same arguments, does it end in the same state? An update that sets fields to given values usually is. A create is not, because a retry makes a second post. That's idempotentHint

• Does it only read? Then say so, so clients don't nag the user on every list call

Agents retry. A timeout in the middle of a create is exactly when a client will call it again, so I think idempotency matters more here than in a normal API where a human clicks a button once

The other tool design choice that mattered: small, boring tools instead of a few clever ones. list_blogs returns the blogId every other tool needs. create_post requires only blogId, title and content, and everything else is optional. get_post reads back what the server actually stored. Server-side limits (10 tags, 50 characters per tag, 100 characters for a slug) get enforced in validation, not left to the model to remember

I also had a case where create_post failed on a fresh blog because it expected a collection to exist that a new user hadn't set up. Our bug. A human would figure that out from the dashboard. An agent just gets an error and guesses

Images: base64 over MCP

upload_image takes the file as base64 in a data field, with filename, mimeType and the blog ID, up to 8 MB decoded. It returns a path you then set as the post image

The reason is boring. An MCP tool call is JSON-RPC, so arguments are JSON. There's no multipart body to stream a file into. The REST API takes a normal multipart upload, and a featured image can be set from a URL you already host

Base64 passes through the model's context though, so a big image burns a lot of tokens before it even reaches the server. Resizing first helps a lot. Upload-from-URL over MCP would fix most of it and I haven't built it yet

Letting an agent touch a live blog

The thing I worried about most is an agent publishing something half-finished to a real audience

So status on create_post defaults to draft. Publishing is a separate update_post call that sets status to published. I'd rather the agent need one extra explicit instruction to go public than have one missed instruction make it public

Some other things that help:

• Revisions are exposed as tools (list_content_revisions, get_content_revision), so if an agent overwrites a draft you edited by hand, the earlier version is still there

• Reading back with get_post after every write. What the model says it did and what the server stored are not always the same thing

• Content goes in as HTML, which means code blocks with a raw <div> inside them can turn into real markup if the conversion is sloppy. A draft you look at rendered catches that. A direct publish doesn't

What I haven't solved is the delete case. With one scope, delete_post is available to any connected client, and the only real guard is the client asking before a destructive call (which depends on the annotations being right) and the user actually reading the prompt

Not sure how many ppl want an agent anywhere near a live blog in the first place. If you've built a write-capable MCP server, how did you split your scopes?

If you want to poke at it, the MCP endpoint is https://justblogged.com/mcp and tools/list works without an account