Convincing Google I'm still the same person

The redesign was the visible part. The domain move was the real work.

Ten days ago I launched a redesign of this site and moved it from aleksandarpopovic.com to alekspopovic.com at the same time. If you clicked an old link to get here, you probably didn't notice anything. That was the goal. A successful domain migration is one where nothing seems to happen at all.

Getting there took more work than I expected, and almost none of it was design or code. It was redirects, canonicals, and convincing Google that the person at the new address is the same person who lived at the old one. I also came very close to shipping an infinite redirect loop, which I'll get to.

Why change the domain at all

The old domain used my full formal first name and my surname without the ć. Meanwhile my YouTube channel is @alekspopovic. So is my GitHub, my LinkedIn, my Instagram, and my dev.to. The domain was the one place where I spelled my own name differently, and it was also the longest possible version of it.

The site now lives at alekspopovic.com and displays one name, Aleks Popović, which matches every handle I have. The other spellings are still real (people call me Alex at work and Aleksandar in person), so they moved into the structured data as alternate names. If you search for any version of my name you still end up here, but nothing on the site has to display all three.

That covers the identity half of convincing Google I'm the same person. The technical half is the rest of this post.

One decision made everything easier

I was rebuilding the site anyway, moving from Gatsby to Next.js, which is a story for another post. That gave me a choice: launch the redesign on the old domain and switch domains later, or do both at once.

Doing both at once sounds riskier, but it's actually the safer option if you can keep every URL path identical. Same post slugs, same section pages, same tag pages. When the paths match, the entire old domain can be handled with a single path-preserving redirect, and search engines re-index the site once, at its final address. Splitting it into two launches means they re-index everything twice, with an awkward transition period after each one.

So that became my rule for the whole migration. The domain changes, but nothing after the slash does.

On Vercel this part is surprisingly easy. You add the old domain as a secondary domain and it responds with a path-preserving 308 redirect to the new one. No per-URL rules and no redirect maps.

Finding out what would have silently broken

A redirect only helps if the new site actually serves what the old one did. Before the cutover I went through the live old site URL by URL and compared it against the new build. I'm glad I did, because the redesign had quietly dropped a few things I forgot existed:

• The RSS feed. The old site served /rss.xml, and people are subscribed to it in their feed readers right now. The new site advertised /feed.xml in its metadata, and that route didn't even exist. I built the feed and redirected the old path to it. Feed subscribers are the easiest audience to lose because nothing visibly breaks for them. New posts just stop showing up.
• Tag pages. The old site had a tags page and eleven individual tag pages, all indexed, all with nowhere to land on the new site. I rebuilt them from the post frontmatter and lowercased the URLs to match the old ones.
• The web manifest at its old path, and a proper og-image. Without the image, sharing any page that didn't have its own picture would show a broken card.

None of these would have thrown an error on launch day. They would have quietly rotted until someone mentioned them months later, which is what makes migration bugs so annoying to catch.

Adding the canonicals I never had

I'll admit that the old site had no canonical URLs at all. I got away with it for years, but a domain move forces the issue. Without canonicals, Google has to guess which address is the real one, and that's exactly the guess you don't want it making while you're switching domains.

By the way, canonicals aren't just for copies of a page pointing back at the original, like my dev.to cross-posts do. The original should also point at itself, because tracking parameters and other URL variations quietly create duplicates of every page, and a self-referencing canonical is what tells Google which version all of that credit belongs to.

If you're doing this in Next.js, one detail worth knowing: don't set the canonical in the root layout. Metadata is inherited, so every page on your site will happily claim to be the home page. Each page needs to declare its own.

The redirect loop I almost shipped

This was the genuine surprise of the project, and it comes down to a GitHub Pages behavior I didn't know about.

Over the years I've published seven small standalone apps, mostly tutorial demos, each from its own repo through GitHub Pages. Because my user-site repo had the custom domain configured, GitHub applied that domain to every project repo on my account. That's how they all ended up being served under my domain, at paths like aleksandarpopovic.com/covid19/, without me ever deciding that should happen.

The part I didn't know is that while the custom domain is set, the github.io URLs are not a fallback, because they redirect to the custom domain. So after the DNS cutover both routes would lead to the new site, and all seven demos would just go dark. That includes the live demos linked from my two most popular tutorials.

To fix it I had to do two things, in this exact order:

1. Add redirects on the new site that send each of those paths back to its github.io home.
2. After DNS moves, disable Pages on the user-site repo. That drops the inherited domain and lets the demos serve from their own github.io URLs again.

If you skip the second step, the redirects don't fail with a 404. They just keep looping. The demo path redirects to github.io, which redirects to the old domain, which redirects to the new site, which redirects to the demo path again.

Not every redirect should be permanent

The main domain redirect is permanent, obviously. The old address is never coming back.

But I made the demo app redirects temporary on purpose. Browsers cache permanent redirects indefinitely, and those demos might move to subdomains of the new domain at some point. A cached permanent redirect would make that future move painful for anyone who had ever visited. A temporary redirect also keeps my branded URL as the indexed entry point instead of handing the search result over to github.io.

Before this project I treated permanent vs temporary as a formality. Now I think of a permanent redirect as a commitment, and I only make it when I actually mean it.

The cutover

Launch day itself was just a runbook: deploy, point DNS at the new site, add the old domain as the redirecting secondary, disable Pages on the user-site repo, then submit a change of address in Google Search Console.

The change of address is the step people tend to skip because the redirects should be enough. They mostly are, but the change of address is you telling Google directly what the redirects only imply, and it shortens the period where search results still show the old domain. In my case Google took the hint without any drama.

I can even put a number on it. Ten days after the move, Google is already the site's second biggest source of traffic, right behind LinkedIn. And the pages it sends people to are my old tutorials, living on the same slugs they have had for years, just on a new domain. That is what all of the redirect and canonical work was for, and it is very satisfying to watch it pay off this quickly.

The loose end I decided not to close

One thing from this migration is still open, and I left it that way on purpose. Over the years I cross-posted seventeen articles to dev.to, each with a canonical URL pointing at the old domain. I could edit every one of them and point it at the new domain, but that means manually going through seventeen posts, and I don't really need to. The redirect already carries every one of those links to the right place.

Keeping the old domain registered was never in question anyway. It has my name on it, and I would rather pay a small yearly fee than find out in five years who picked it up and what they are doing with it. But if you're in a similar situation and thinking about letting your old domain go, know what you would be giving up. The day it lapses, every cross-post canonical and every old link out there starts sending its value to a dead address, or worse, to whoever registers it next. So aleksandarpopovic.com stays on auto-renew, doing nothing but forwarding traffic, and those seventeen posts can point at it for as long as they like.

The checklist

Everything above, compressed into what I would hand my past self:

1. Keep every URL path identical if you possibly can. It turns the whole migration into one redirect rule.
2. Audit the live old site before cutover. Feeds, tag pages, manifests, share images, and any URL you forgot you ever published. Assume the quiet stuff is broken until proven otherwise.
3. Add canonicals to the new site before launch, not after.
4. Check for inherited domain behavior. GitHub Pages, subdomains, anything else living under your domain that you forgot about.
5. Decide deliberately which redirects are permanent and which are temporary.
6. Write down the cutover order and follow it: deploy, DNS, secondary domain redirect, external cleanup, Search Console change of address.
7. List all external canonicals (cross-posts, syndicated articles) before you let the old domain expire. Either update them at the source or keep the old domain registered for as long as they point at it.
8. Document the traps in the code, right next to the config that trips them.

The redesign is the part people saw and complimented, but the migration is the part that made sure they could still find the site at all. If you end up moving your own site to a new domain, I hope this list saves you from at least one redirect loop. And if you run into a trap I didn't cover here, send me a message. I would love to hear about it.