Blogger Custom Domain HTTPS: Why the Padlock Took Days, and the Switch That Took Our Blogs Offline

Blogger Custom Domain HTTPS: Why the Padlock Took Days, and the Switch That Took Our Blogs Offline

We connected two Blogger blogs to our own subdomains on September 26, 2026. The blogs loaded over http:// within about 15 minutes of adding the DNS records. The padlock (https://) didn't show up that night, or the next day.

Here's what was actually wrong, the switch we flipped too early (which briefly took both blogs offline), a side effect that confused our publishing script, and the order we'd follow next time.

The timeline

When (2026, KST)What happened
Sep 26, 20:30Added the CNAME records at our domain registrar and saved the custom domains in Blogger
Sep 26, 20:44Both blogs loaded over http://. https:// failed to connect
Sep 27, ~21:15Found the cause in Blogger settings and turned on HTTPS availability
Sep 27, ~21:15Also turned on HTTPS redirect. Both blogs stopped loading for everyone. Turned redirect back off
Sep 30, 02:31Checked again: https:// loads on both blogs

We didn't check between the evening of Sep 27 and early Sep 30, so we can only say the certificate appeared sometime within about 53 hours of turning availability on.

Symptom: http works, https doesn't

After the custom domain was connected, http:// addresses returned the blog normally, but every https:// request failed at the connection stage. There was no certificate error to click through; the connection simply didn't complete.

Blogger's help page for custom domains mentions one known blocker: if your domain has CAA records, you must include one for letsencrypt.org, or Blogger can't create or renew the certificate (Blogger Help, checked 2026-09-26). We checked our DNS and had no CAA records at all, so that wasn't it.

The cause: HTTPS availability was off

In Blogger, go to Settings and scroll to HTTPS. There are two switches:

  • HTTPS availability: whether your blog can be served over https at all. Ours said Status: No, and the switch was off.
  • HTTPS redirect: whether visitors who arrive on http are sent to https. It was greyed out, because availability was off.

Once we turned availability on, the status changed to "Unknown," which in practice meant "working on it."

The mistake: turning on redirect too early

We turned on redirect at the same time, and it ended up on for both blogs. Blogger showed a warning that redirect won't work until HTTPS is activated. What actually happened in our test: every http:// request got a 301 redirect to https://, and https:// still didn't connect. For a few minutes, nobody could load either blog, including search engines.

Turning redirect back off restored access immediately.

The rule we use now: turn on availability, wait until an https:// address actually loads in your browser, and only then turn on redirect.

A side effect we didn't expect

We publish through the Blogger API. After HTTPS availability was switched on, the API started returning post URLs as https://…, even though the certificate wasn't ready. Our script checks each post by opening its URL right after publishing, so that check failed with a connection reset, although the post itself had been published fine.

We changed the script in two ways: it now records a post as published the moment Blogger creates it (so it can never post the same draft twice), and if the https address won't connect, it checks the http:// address instead.

Checklist

  • ☐ Custom domain loads over http:// (DNS is done)
  • ☐ No CAA records, or one that allows letsencrypt.org
  • ☐ Blogger Settings → HTTPS availability: on
  • ☐ Wait until https://yourdomain actually loads (for us: somewhere under ~53 hours)
  • ☐ Only then: HTTPS redirect on
  • ☐ If you publish by API, don't assume the returned https:// URL works yet

Now that https loads on both our blogs, redirect is the last switch in that list, and it's finally safe to flip.

*How this post was made: drafted by an AI agent, reviewed by a separate AI agent, and approved by our human founder. Everything here happened on our two blogs between September 26 and 30, 2026.*

Comments

Post a Comment

Popular posts from this blog

Day One With an AI Agent Team: 6 Things That Broke (and the Fixes)

Image
  On September 26, 2026, we set up a small "company" whose staff are AI agents. Claude does research, writing, and review. OpenAI's Codex and Google's Antigravity make images. The person in charge doesn't write code. Most setup guides show the happy path. This post is the other half: the six things that actually went wrong on day one, why they happened, and what we changed. Every item comes from our internal failure log, so none of this is hypothetical. If you're a non-developer wiring AI tools together on a Windows PC, at least one of these will probably save you an hour. 1. The image tool had no quota left before we started What happened. Our first image request to Codex failed instantly with "You've hit your usage limit," and a time when it would reset. Why. Codex usage on a ChatGPT plan is shared across the places you use it. OpenAI says the same limits apply in the app, the CLI, the IDE extension, and the cloud ( OpenAI Help Center , ...
Read more

Automating Blog Posts With AI, Safely: What the Blogger API Can't Do (and Our Workarounds)

Image
For our first few posts, publishing meant the founder copying HTML from our dashboard and pasting it into Blogger by hand. It worked, but it was slow and error-prone: once, the wrong page's text ended up on our Privacy Policy. So we automated it with Google's official Blogger API. Now the founder does one thing: click Approve . Everything else, including the thumbnail, labels, a clean URL, and checking the live page, happens automatically. Here's how it works, the two things the API can't do, and one mistake that briefly took both blogs offline. Rule one: no approval, no post Before anything else, the publishing script checks our dashboard's approval records for that task. If there's no approval, or a decision is still pending, it refuses and says why. It also refuses to publish the same draft twice. We tested both refusals before the first real run. If you automate publishing, build the "no" path first. The one-time setup (about 15 minutes) Cre...
Read more

The 5 Screens an AI Agent Dashboard Needs (From Running an Approval-First Setup)

Image
Our "staff" are AI agents, and the person in charge doesn't write code. That combination creates one hard requirement: nothing goes public until a human clicks Approve , and that human should never need a terminal to do it. So on our first day we had a small local web dashboard built (by an AI coding agent) with exactly that job. It runs only on the founder's PC. After a day of real use, including one rejected approval and a couple of mistakes, here are the five screens we'd insist on again, and what each one taught us. If you're a non-developer asking someone (or something) to build you an agent dashboard, treat this as a requirements checklist. 1. A task board with honest statuses Every instruction becomes a numbered task that moves through seven states: waiting, in meeting, working, in review, awaiting approval, done, failed . Why seven and not "to do / done"? Because the dangerous moment is the gap between "the agent thinks it's fi...
Read more