Two blog posts we'd deleted months ago were still showing up on our /blog landing page. That was strange enough. But clicking either of them didn't return a 404. Instead, the browser just spun. Infinite redirect loop. No error. No resolution. Just a page that would never load.
This is how we traced it back to four redirect rules nobody remembered creating.
What we found when we looked
The two ghost posts were ai-generated-test-suites-one-day and hubspot-api-blog-publishing-automation. Both had been removed from the CMS, but the blog listing page still surfaced them as if they were live content.
The first instinct was a caching issue. Stale listing page, maybe. But the redirect loop was the louder symptom. A caching bug doesn't send your browser into an infinite request cycle. Something was actively routing these URLs in circles.
So we went to the place in HubSpot where routing lives: Settings → Content → Domains & URLs → URL Redirects.
That's where we found four regex-based redirect rules, all created on the same day five months earlier, all tied to portal 557351.
Here's the problem. Rule 1 redirected /blog/* to /insights/*. Rule 2 redirected /insights/* back to /blog/*. Both had the same priority value: 1999979601.
Read that again. Every request to a /blog/ URL got sent to /insights/. Every request to an /insights/ URL got sent right back to /blog/. Same priority. No tiebreaker. The browser would bounce between them until it gave up.
The remaining two rules routed traffic to and from a HubSpot staging domain (axelerant-557351.hs-sites.com/axelerant-blog), which added more confusion to the request chain but wasn't the primary loop trigger.
Why these rules existed in the first place
We traced the creation date and the author. All four rules had been set up in November 2025, likely as part of a planned URL migration from /blog to /insights. That migration either stalled or was abandoned. The rules stayed.
When we asked the original author, the response confirmed that the old pages had since been moved to new URLs through other means. The redirect rules were orphaned artifacts of a migration that moved on without cleaning up after itself.
This is the part that matters: HubSpot does not validate redirect rules against each other at creation time. You can create two rules that form a perfect loop, and the platform will accept both without a warning. There's no circular reference check. No conflict detection. No alerting when a loop goes live.
These rules sat in production for five months without anyone noticing. It's possible they caused problems earlier that were attributed to something else or simply went unreported. We don't have the data to say.
What we did
The engineer who diagnosed the issue proposed two options. Option one: delete all four rules. Option two: keep the /insights/* → /blog/* rule in case any old /insights deep links were still circulating and needed to resolve.
After confirming with the original rule creator that all content had been migrated through other paths, we went with option one. All four rules were removed.
The fix went live the next morning. Total turnaround from diagnosis to resolution was about 13 hours.
What this actually teaches
The technical fix was simple. The diagnostic work was not. The real difficulty was that the symptom — ghost posts on a listing page, redirect loops on click — didn't immediately point to URL redirect configuration. Redirect rules in HubSpot are silent infrastructure. They don't log. They don't surface in content dashboards. They just act on every matching request.
If you manage a HubSpot portal, here's a short audit you can run right now.
1. Review all regex redirect rules
Go to Settings → Content → Domains & URLs → URL Redirects. Filter for regex rules specifically. Simple string redirects rarely conflict. Regex rules with wildcards can overlap in ways that aren't visible at a glance.
2. Check for opposing direction pairs
If path A redirects to path B and path B redirects to path A, you have a loop. HubSpot won't tell you this. You have to look.
3. Check priority values
Rules at the same priority with overlapping patterns are unpredictable. If you must keep both, differentiate their priority so one clearly wins.
4. Audit after migrations
Any time a URL restructuring is completed, abandoned, or paused, go back and clean up the redirect rules that were created for it. They don't expire. They don't deactivate. They just keep running.
5. Test the paths
Open an incognito window and manually hit the source URLs of your redirect rules. If the page loads, you're fine. If it loops, you have a conflict. This takes two minutes and catches problems before your visitors do.
Redirect rules are configuration debt. They accumulate quietly, especially in a CMS where multiple people have admin access and migrations happen in stages. The five-month gap between creation and detection in our case wasn't negligence. It was the natural outcome of a platform that doesn't surface its own conflicts.
Check your redirects. Especially the regex ones. Especially the ones you forgot about.
Bring this dispatch into a working session - one page in, scoping memo out.
Brief Foyer