Rebrand without losing SEO: our dgtl.io to withdgtl.com playbook

We recently changed our own domain. dgtl.io became withdgtl.com: one live site, 141 built pages across English and Spanish, 20 blog posts with rankings we didn't want to torch, and a sales pipeline mid-conversation on the old email addresses.

Here's what nobody tells you about domain changes. Google handles 301s well and has for a decade. What hurts you is everything else: the hardcoded canonical nobody checked, the JSON-LD logo still pointing at the old host, the DKIM record that never got created on the new domain so your proposals land in spam the same week you announce the new name. Those losses are silent. Nothing errors, nothing alerts, and the damage compounds for months before anyone connects it to the rename.

This is the playbook we ran on ourselves. Steal it.

Start with a reference audit, not a redirect map

Before touching DNS, we ran a search across the whole codebase and content library for the old domain. The count came back at 87 hardcoded references. Not eight. Eighty-seven, in a codebase we'd call disciplined.

They clustered into six buckets:

1. Canonical URLs and hreflang alternates in the metadata layer
2. Open Graph and social card image URLs
3. JSON-LD structured data: the Organization url, the logo, the publisher on every Article
4. Sitemap and RSS configuration
5. Transactional email templates and the addresses inside them
6. Plain markdown links inside blog posts

Plus a long tail we didn't predict: two environment variables, the CSP config, the web manifest, a Cal.com redirect, and a GitHub Actions workflow that pinged the old URL as a health check.

Every reference went into a sheet with three columns: file, bucket, owner. The audit took two days, and they were the two most valuable days of the migration. Skip this step and you'll ship a site that redirects perfectly while telling Google, inside its own structured data, that it still lives at the old address.

301s: boring, single-hop, forever

The redirect layer is where everyone fixates. It's the easy part. Five rules:

Path-preserving and wildcard. old-domain.com/blog/post redirects to new-domain.com/blog/post, with wildcard coverage for subdomains and paths you've forgotten exist.

One hop. Old HTTP to old HTTPS to new HTTPS is a chain. Every extra hop dilutes signal and adds latency. Resolve it at the edge, not in the application.

Query strings survive. Our attribution model depends on utm parameters and the ?source= slug arriving alive on the other side.

Permanent status codes. 301 or 308, never 302. A temporary redirect tells Google to move nothing.

The old domain never expires. We renewed dgtl.io for ten years. The authority flowing through those redirects evaporates the day the registration lapses, and expired domains of real companies get bought and used for phishing.

Then test like you mean it. Export the top 500 URLs by impressions from Search Console, run every one through curl, and assert a single-hop permanent redirect to the identical path on the new domain. Ours caught three paths that bounced through a legacy redirect from an earlier restructure, turning one hop into three.

Search Console and the two-property window

Sequence matters more than speed:

1. Verify the new domain property via a DNS TXT record days before the flip.
2. Flip DNS and deploy the redirects.
3. Submit the Change of Address from the old property.
4. Resubmit both language sitemaps on the new property.
5. Keep both properties open for at least six months.

The useful signal lives in the old property: 404s from forgotten paths, backlinks pointing at strange legacy URLs. For us the wobble lasted two to four weeks of dipped impressions before the curves returned to trend. That matches what Google documents and almost nobody believes: rankings transfer. They transfer if, and only if, the redirects are total and the on-page signals agree with them.

Email is where rebrands quietly die

A new domain has zero sending reputation. If you flip your website and your email on the same day, you've combined a rankings wobble with a deliverability crater, voluntarily.

Stagger them. Our sequence, spread across six weeks:

• Week 1: create the sending domain on your email platform, publish SPF and DKIM (two 2048-bit keys, so you can rotate later), and DMARC at p=none with aggregate reports on.
• Weeks 2 to 5: warm the domain with low-volume real mail. Internal threads, a handful of client threads, the newsletter to your most engaged segment. Read the DMARC reports weekly.
• Week 6: move transactional and outbound volume, then tighten DMARC to p=quarantine.

Keep the old domain's mailboxes alive and forwarding for at least a year. Prospects mid-deal will reply to old threads, and those replies have to land.

The asset sweep and the one-cut rule

The last pass is identity: regenerate OG images with the new wordmark (we have five dynamic OG routes and all five had the old logo baked in), swap the favicon and manifest icons, update the logo URL in the Organization JSON-LD, social bios, email signatures, proposal templates, the GitHub org. LinkedIn and Slack cache link previews for weeks, so force a refresh with each platform's sharing debugger where one exists.

And here's the opinionated part: do the cutover in one cut. The "transition period" where both domains serve the live site is the worst option available. It splits your link authority, creates duplicate content, confuses the knowledge graph about which entity you are, and trains your own team to keep sharing old URLs because they still work. Pick a date, move the website and assets within 48 hours, let email follow its own warm-up calendar, and let the 301s do their job.

All of this runs on a checklist for one reason: every failure mode in a migration is silent by default. The site stays up and the demo goes fine, and six weeks later someone asks why organic leads dropped 30% and nobody thinks of the DKIM record.

One more thing this migration confirmed for us. A rebrand is Studio work and Marketing work in the same sprint. Naming, wordmark, and asset system on one side; technical SEO, redirects, and deliverability on the other. Hand it to a brand agency alone and you get a beautiful identity with cratered rankings. Hand it to an SEO shop alone and you keep the traffic while shipping a weaker brand. It's the same argument we made in why we built DGTL in Quito: the practices work better together. If a rename or domain change is on your roadmap, Studio runs the identity side and Marketing runs the search side, under one contract.

Related: Brand design that converts → · Topic clusters and GEO → · Why Quito →