Forem: Nikola

I Switched Domains Based on ChatGPT's Advice and Lost All My Google Rankings (4 Month Migration Case Study)

Nikola — Fri, 13 Feb 2026 23:29:21 +0000

In late 2025, I revived a project I'd put on hold for years.

I had two domains:

hostedstatus.page - Ranking #1-3 for "hosted status page" on all search engines
statuspage.me - Sitting unused since 2018

I asked ChatGPT: "Which domain should I use?"

ChatGPT said: "statuspage.me is catchier and more memorable. Switch to it."

I trusted the AI.

I did a proper domain migration:

301 redirects from hostedstatus.page → statuspage.me
Google Search Console domain change notification
Bing Webmaster Tools migration
Yandex domain change

Everything by the book.

Four months later:

Google: Invisible (page 10+)
DuckDuckGo: Page 1, position #3
Bing: Multiple page 1 rankings
ChatGPT: Citing my content

Here's what actually happened when I migrated domains — and why different search engines behave so differently.

The Setup

I've been building StatusPage.me - a status page and monitoring service for indie hackers, SMBs, SaaS companies, etc. The product differentiates through indie-first pricing, an OSS Hero program (free for open source projects), and affordable pricing.

Back in ~2018, I registered both domains:

hostedstatus.page - Self-documenting, clear value prop
statuspage.me - Shorter, snappier, competing with statuspage.io

I built the initial version on hostedstatus.page, but the product went on hold due to an employment contract with an IP clause. During those years, hostedstatus.page sat there, accumulating some organic search authority.

In 2025, I left that job and revived the project. I immediately decided to migrate to statuspage.me and asked ChatGPT for confirmation.

The Decision

ChatGPT's reasoning seemed solid:

"statuspage.me is catchier, more memorable, and easier to say. It competes directly with statuspage.io in people's minds. The shorter domain is better for branding."

This felt right. hostedstatus.page was wordy and defensive. statuspage.me was confident and clean.

What I didn't consider: I was asking for branding advice, not SEO advice.

For a bootstrap SaaS dependent on organic traffic, that's a critical distinction.

The Migration (Done Right)

I did everything correctly:

301 redirects from every hostedstatus.page URL → statuspage.me equivalent
Google Search Console "Change of address" tool
Bing Webmaster Tools domain migration notification
Yandex domain change submission
Updated all backlinks I had control over

This is textbook domain migration. Every SEO guide says this is how you do it.

And it worked... sort of.

The Crash (Google)

Google rankings before migration:

"hosted status page": Position #1-3
"status page": Lower first page / page 2
Clean organic traffic from search

Google rankings 4 months after migration:

"hosted status page": Page 10+ (invisible)
"status page": Page 10+ (invisible)
Organic traffic: Significantly reduced

Google Search Console showed:

⚠️ "This site is currently moving to statuspage.me"
✅ Pages being indexed (621 indexed pages)
❌ Link data: "No data" (authority not yet transferred)

The migration was recognized but not processed.

The Plot Twist

After sharing my story on X, my wife suggested I check other search engines.

I had been so focused on Google that I hadn't looked elsewhere.

DuckDuckGo results:

Searching "status page":

Position #3: My blog post "What Is a Status Page? The 2026 Practical Guide"

Searching "statuspage":

Position #3: StatusPage.me homepage
Beating Status.io, Better Stack, StatusGator

Bing results:

Searching "statuspage":

Multiple page 1 listings for statuspage.me
Blog post + homepage both ranking

ChatGPT search:

When people ask ChatGPT about status pages, it cites my blog post as a reference source.

Google results:

Searching "status page":

Invisible. Page 10+.

What I Learned: Different Engines, Different Timelines

Domain migrations don't happen uniformly across search engines.

DuckDuckGo / Bing:

Processed the 301 redirects in 2-4 weeks
Transferred most link equity quickly
Content quality weighted heavily
Freshness and relevance prioritized

Google:

Takes 6-12 months to fully transfer authority
More conservative about domain migrations (anti-manipulation)
Heavier emphasis on domain age and backlink history
Competitive keywords get extra scrutiny

The technical migration was done correctly. The difference is algorithmic philosophy, not execution.

Why Google Is Slower

Google's caution makes sense from their perspective:

Domain migrations can be gamed - Buying aged domains to inherit authority
Competitive keywords = higher scrutiny - "status page" is a commercial keyword
Authority takes time to validate - Google wants proof the new domain deserves the old rankings
Link graph recalculation is expensive - Backlinks need to be revalidated

Bing and DuckDuckGo recovered faster because they weight content quality and freshness more heavily than domain authority history.

The Data Backs This Up

My domain metrics:

Domain Rating: 36/100 (respectable)
Referring Domains: 72
Domain Age: 6 years, 11 months (registered 2018, but unused until late 2025)

The backlinks exist. Google just hasn't credited them yet.

Meanwhile, DuckDuckGo and Bing saw the 301s, validated the content, and moved on.

What Didn't Work: The Directory Submission Grind

I'll be honest about something that wasted time: directory submissions.

After the migration, I submitted statuspage.me to dozens of directories. The metrics looked promising:

Domain Rating climbed from 1 → 36
Referring domains grew from 1 → 72
Backlink count hit 1,668

The result?

Organic traffic: 0 (until Jan 2026, then 1 visit/month)
Google rankings: Still page 10+
Actual conversions: 0

Directory links are vanity metrics. They raise your DR number, but most directories have little to no authority themselves. Google doesn't value them.

What actually drove results:

Quality blog content on dev.to
DuckDuckGo/Bing ranking my actual helpful content
ChatGPT citing my blog post

The lesson: One well-written, genuinely useful blog post > 50 directory submissions.

Was It A Mistake?

Short answer: No, but with caveats.

What I got right:

statuspage.me is a better brand name
Technical migration was done correctly
Content quality maintained
Long-term positioning improved

What I got wrong:

Underestimated Google's migration timeline
Didn't check other search engines sooner (would've panicked less)
Wasted time on directory submissions
Didn't consider that "better branding" has a 6-12 month SEO tax

The real lesson:

ChatGPT gave me branding advice when I needed SEO + business context advice.

For a bootstrap SaaS dependent on organic traffic, throwing away established rankings has a cost — even when done correctly.

The question I should have asked: "Can I afford 6-12 months of reduced Google traffic?"

AI Search Engines - The Mixed Results:

Perplexity.ai:

When asked about status pages, Perplexity listed statuspage.me alongside Status.io, Atlassian Statuspage, and UptimeRobot, highlighting "Multi-region checks, OSS-friendly."

ChatGPT:

Cites my blog post "What Is a Status Page?" when people search for status page information.

Gemini (Google's AI):

When I explicitly asked about statuspage.me, Gemini provided detailed analysis, seamingly from an outdated site.

But notably: When asked for general recommendations, Gemini suggested Better Stack, UptimeRobot, and Instatus - not statuspage.me.

The takeaway: AI search engines are discovering statuspage.me (Perplexity, ChatGPT), but Google's own AI (Gemini) still defaults to more established brands. The same pattern as Google Search itself.

What This Means For You

If you're considering a domain migration:

✅ Do migrate if:

You have multiple traffic sources (not just SEO)
The new domain is significantly better for branding
You can afford 6-12 months of reduced Google traffic
You're patient and have runway

❌ Don't migrate if:

Google organic is your primary traffic source
You're pre-launch or early stage
You need immediate results
Current domain is performing well

If you're in the middle of a migration:

Don't panic if Google rankings drop
Check Bing/DuckDuckGo - they recover faster
Monitor Google Search Console for migration status
Keep 301 redirects in place for at least 12 months
Continue publishing quality content
Skip the directory submissions - focus on real content

What I'm Doing Now (4 Months In)

The current state:

DuckDuckGo: Page 1 rankings ✅
Bing: Page 1 rankings ✅
ChatGPT: Content being cited ✅
Google: Slowly climbing back ⏳

Example links:

Active strategies:

Building in public on X (@IT_mafija)
Writing technical content on dev.to (previous posts)
Direct outreach to indie hackers and OSS projects
Long-tail SEO for less competitive keywords
IndexNow integration - Auto-submitting new/modified pages

On the IndexNow implementation:

About a month ago, I added IndexNow to my internal tooling. It detects new blog posts, docs, and page updates, then (with my approval) submits them to Bing, DuckDuckGo, and Yandex.

Google doesn't support IndexNow - they rely on crawling and sitemaps.

This gives Bing/DuckDuckGo a structural advantage: I can tell them immediately when content changes, rather than waiting for their next crawl.

It's a small thing, but it compounds. Fresh content gets indexed in hours instead of days.

Practical Takeaways

For domain migrations:

Google takes 6-12 months - this is normal, even with perfect execution
Bing/DuckDuckGo process migrations 10-20x faster
Different search engines = different algorithmic priorities
Check ALL search engines, not just Google
IndexNow helps Bing/DDG (but Google doesn't support it)

For bootstrap founders:

"Better branding" has a real SEO cost
Directory submissions are vanity metrics
One quality blog post > 50 directory links
Content that gets cited by ChatGPT = new distribution channel
DuckDuckGo/Bing traffic is real (especially from tech-savvy users)

For anyone asking AI for advice:

Specify your constraints (bootstrap, SEO-dependent, timeline)
Ask for business context, not just branding advice
AI doesn't understand your specific situation
Get multiple perspectives before big decisions

The Uncomfortable Truth

Most domain migration guides focus on technical execution.

They assume all search engines behave the same way.

They don't.

Google's 6-12 month timeline is real, documented, and unavoidable - even when you do everything right.

If you're dependent on Google traffic and can't afford that gap, the "better domain" might not be worth it.

But if you can weather the storm, the long-term brand positioning might justify the short-term pain.

I'm 4 months in. Ask me again in 12 months.

Building StatusPage.me - status pages + monitoring for indie hackers.

The domain migration journey continues. Follow along: @IT_mafija | statuspage.me

Removing Third-Party Dependencies Made My Status Page Faster (Here’s How)

Nikola — Wed, 11 Feb 2026 09:53:43 +0000

When I wrote about why a status page shouldn’t depend on third-party CDNs, the immediate response was predictable:

“Sure, but CDNs are faster.”

That assumption is so common it rarely gets tested. So I tested it.

I removed all third-party runtime dependencies from my status pages.

Nothing broke.

Performance improved — materially.

Not because of a trick, but because I removed architectural friction.

Fewer requests
Smaller payloads
More predictable render behavior
Lower TTFB

To make this concrete:

Europe TTFB dropped from ~3s to ~181ms
America dropped to ~530ms
Asia Pacific dropped to ~861ms
JavaScript bundle shrank from ~1MB to ~45KB

Europe benefited the most because it’s closest to the primary infrastructure. Other regions are still bounded by geography.

What changed wasn’t physics.
It was server-side inefficiency.

The architectural bottlenecks are gone.

What Didn't Change

Geography still matters.

Layered caching removes server-side bottlenecks.
It does not remove physical distance.

The goal wasn't to beat latency physics.
It was to remove unnecessary self-inflicted delays.

This isn’t an anti-CDN rant. CDNs are incredibly useful for many workloads. But a status page is not “many workloads.” It’s a very specific type of system with very specific goals.

What Comes Next

Layered caching removed most self-inflicted latency.

What remains is mostly geography.

The next step is introducing read-only replicas in additional regions to reduce cross-region database round-trip time.

Caching removes unnecessary work.
Regional replicas reduce distance.

They solve different problems.

Layered caching made the system efficient.
Replicas will make it geographically closer.

They’re complementary, not interchangeable.

How I Actually Sped It Up

There wasn’t one magic change. I removed a chain of small delays.

The biggest wins came from:

Letting Caddy handle more of the boring HTTP work (compression + headers)
Layered caching (browser → Redis → in-process → filesystem)
Shrinking what the browser downloads and executes

The result wasn’t just better synthetic metrics. It felt faster.

Before these changes, the cache hit rate was effectively 0% and the performance grade reflected that. After introducing layered caching and proper HTTP policies, repeated requests became dramatically cheaper.

a screenshot of https://status.statuspage.me test results

1. Caddy Tuning: Compression + Explicit Cache Policy

Caddy is great out of the box. But status pages are perfect for aggressive HTTP fundamentals.

example.com {
    encode zstd gzip

    # HTML: short-lived or revalidated
    @html path / /status* /incidents* /history*
    header @html Cache-Control "public, max-age=0, s-maxage=30, must-revalidate"

    # Fingerprinted assets: cache "forever"
    @assets path /assets/* /static/*
    header @assets Cache-Control "public, max-age=31536000, immutable"

    file_server
}

Most of my pages behave like “mostly static + occasional updates.”

So HTML is short-lived. Assets are immutable.

That alone reduced repeat downloads to near-zero.

2. Static Files: Make Repeat Visits Cheap

If fonts, icons, JS bundles, and CSS aren’t cached hard, you pay the same cost on every visit.

@fonts path /fonts/* /assets/fonts/*
header @fonts Cache-Control "public, max-age=31536000, immutable"

@images path /img/* /assets/img/*
header @images Cache-Control "public, max-age=604800"

Static delivery is the cheapest request your server can handle.
Ideally it never reaches the app at all.

After fixing headers, repeat-view performance improved dramatically.

3. Redis: Cache Expensive Shared Computations

Redis wasn’t about caching everything.

It was about preventing repeated fan-out queries:

Region summaries
Uptime aggregates
Incident rollups

key := "status:public:v1:region_summary"
if v, ok := redis.Get(ctx, key); ok {
    return v
}

data := computeRegionSummaryFromDB(ctx)

// TTL + jitter to prevent stampedes
ttl := 30*time.Second + time.Duration(rand.Intn(10))*time.Second
redis.Set(ctx, key, data, ttl)

return data

Redis acted as a shock absorber between traffic spikes and the database.

Short TTLs. Shared expensive work cached. Fresh enough, stable enough.

4. In-Process Cache: Stop Hitting Redis for Ultra-Hot Keys

Once Redis is in place, the next bottleneck can be Redis itself.

For ultra-hot keys, a tiny in-memory cache helps.

if v, ok := memCache.Get(key); ok {
    return v
}

v := redisOrDB()
memCache.Set(key, v, 2*time.Second)
return v

It’s a small change, but shaving a few milliseconds off thousands of requests per minute adds up.

5. Filesystem Cache: Serve Pre-Rendered Output

For the hottest pages, I cached rendered artifacts on disk.

Conceptually:

Render final HTML
Write to disk with version/timestamp key
Serve directly when fresh
Regenerate in background when stale

Sometimes “read file and return it” beats “query + render + serialize.”

6. HTTP Revalidation: Cheap Refreshes (304 > 200)

Even when HTML can’t be cached long-term, refreshes can still be cheap.

Short-lived HTML + ETag / Last-Modified means many refreshes become:

304 Not Modified

That’s huge during incidents when users refresh constantly.

7. Asset Minification + Smaller Hydration Surface

I treated asset size like a performance budget.
The JavaScript bundle alone went from ~1MB to ~45KB after removing unnecessary hydration and minifying aggressively.

Minified JS/CSS (Terser)
Removed unused CSS
Compressed with zstd/gzip
Cached fingerprinted assets as immutable

And most importantly:

I reduced client-side hydration.

Status pages are content-first.
They don’t need SPA-level JavaScript.

If the page works without JavaScript, it’s already fast.
Then you add JS only where needed.

The Layered Caching Model

What I ended up with:

Browser cache for immutable assets
Short-lived HTML + revalidation
Redis for shared expensive reads
In-process cache for ultra-hot keys
Optional filesystem cache for rendered artifacts

Each layer reduces work for the layer beneath it.

That’s why the gains stack instead of overlapping.

The Takeaway

For many systems, third-party CDNs absolutely make sense.

For incident communication paths, control often beats theoretical edge distribution.

Removing third-party runtime dependencies did not hurt performance.

It removed hidden latency.
It reduced the failure surface.
It improved repeat-visit behavior.

For status pages, predictability beats theoretical edge performance.

If a status page exists for when things break, it should be built like things will break.

Why a Status Page Should Not Depend on Third-Party CDNs

Nikola — Sun, 08 Feb 2026 12:52:07 +0000

Update: I ended up self-hosting all assets. Nothing broke. Performance improved. ~~Follow-up coming.~~ Follow-up:

https://dev.to/dragstor/removing-third-party-dependencies-made-my-status-page-faster-heres-how-4a17

A status page exists for exactly one reason:

to be reachable when everything else is broken.

And yet, a surprising number of status pages depend on the same third-party infrastructure that often causes the outage in the first place.

This isn’t a theoretical problem. It’s an architectural contradiction.

TL;DR (for busy engineers and founders)

Status pages are critical infrastructure, not marketing assets
Third-party CDNs (including major ones) do have global outages
When a CDN fails, status pages that depend on it often fail silently
A 200 OK page that doesn’t render correctly destroys trust
Fewer dependencies > better incident communication
Boring, self-hosted, dependency-light status pages outperform pretty ones during real outages

If your status page can go down during an incident, it’s not doing its job.

Let’s talk about why relying on third-party CDNs for status pages is a bad idea, what breaks in practice, and which tradeoffs are usually swept under the rug.

Real Recent Outages (2025–2026)

CDNs and edge providers occasionally fail, often in dramatic fashion:

Cloudflare global outage - November 18, 2025

A faulty configuration change caused widespread HTTP 5xx errors across Cloudflare’s network, impacting services such as ChatGPT, X (Twitter), Spotify, and others.

https://www.forbes.com/sites/kateoflahertyuk/2025/12/05/cloudflare-down-new-outage-takes-internet-down-again/
Cloudflare outage - December 5, 2025

Less than three weeks later, another Cloudflare incident affected roughly 28% of all HTTP traffic served by its network due to internal system failures.

https://blog.cloudflare.com/5-december-2025-outage/
Secondary impact on monitoring and reporting tools

During these outages, even third-party outage trackers struggled because they relied on the same CDN infrastructure.

https://deployflow.co/blog/cloudflare-outage-explained/

These weren’t cyberattacks. They were internal misconfigurations and cascading failures that propagated globally because of shared infrastructure.

AWS CloudFront outage - February 10, 2026 Amazon CloudFront suffered a global incident affecting DNS resolution and propagation of configuration changes. Some distributions returned NXDOMAIN, and any changes to CloudFront configs or even creation of new distributions were delayed for hours. Cache invalidations still worked, but that didn’t help teams trying to ship fixes during the outage.

https://thenightly.com.au/society/technology/aws-outage-update-amazon-web-services-cloudfront-experience-global-outage-operation-issue-c-21597705

In short: if your app or status page depended on CloudFront, you might have been up, but unable to change or recover anything when it mattered most.

The Core Paradox

When users visit your status page, something has already gone wrong.

Their app doesn’t load.

Their API calls fail.

Their team chat is on fire.

Now add this to the mix:

Your main app is down
Your CDN is degraded or unreachable
Your status page is… also unreachable

You’ve created a single point of communication failure.

At that moment, the status page isn’t merely useless.

It actively increases frustration, support tickets, and distrust.

“But CDNs Are Highly Available”

Usually.

Until they aren’t.

CDNs can fail in inconvenient ways:

DNS resolution issues
Regional routing failures
TLS or certificate problems
Cached error pages that refuse to expire
Partial outages that affect “only some users”

And when CDNs fail, they often fail globally, loudly, and at exactly the wrong time.

A status page should not share blast radius with:

Your main application
Your analytics stack
Your marketing site
Someone else’s JavaScript experiment

The Silent Failure Mode Nobody Talks About

Here’s the one that causes the most damage.

Your status page responds with 200 OK, but:

External CSS doesn’t load
Fonts time out
JavaScript never arrives

What users see:

Unstyled text
Blank screens
Infinite loading indicators

What support teams hear:

“It works for me.”

What users think:

“They’re hiding something.”

Trust dies quietly here.

Incident Communication Is a Critical Path

During an incident, your status page becomes critical infrastructure.

It is not:

A marketing surface
A design showcase
A frontend playground

Its job is brutally simple:

Load fast
Load reliably
Say something truthful

Every external dependency increases the chance that it fails at the exact moment you need it most.

“Self-Hosting Everything Is Overkill”

It isn’t. It’s an intentional constraint.

Self-hosting forces discipline:

Smaller payloads
Fewer scripts
Fewer fonts
Fewer clever ideas

A status page does not need:

Five font weights
Client-side hydration
A/B testing
Analytics beacons firing during outages

It needs to render. Period.

The Tradeoffs (Because Yes, They Exist)

Avoiding third-party CDNs means:

You handle asset delivery yourself
You lose some edge caching convenience
You think about cache headers and invalidation
You accept “good enough” over perfect Lighthouse scores

Ask the real question:

Do you want your status page optimized for benchmarks, or for reality?

A Simple Rule of Thumb

If a dependency can fail as part of the same incident you’re communicating about, it should not be required for your status page to load.

That includes:

CDNs serving your status page assets
External analytics
Third-party fonts
Tag managers
Anything that blocks rendering while phoning home

Your product may depend on shared infrastructure.
Your status page should not.

Assume the outage affects more than just your app. Design accordingly.

The Uncomfortable Truth

Most status pages are designed for calm days, not bad days.

They look great in screenshots.

They demo well.

They fail quietly when they matter most.

A status page should be boring, resilient, and slightly paranoid.

That’s not a flaw.

That’s the point.

I’m building StatusPage.me around this exact constraint: incident comms that don’t collapse when edge networks do.