Technical SEO field notes for website migrations

Change the address.
Keep the rankings.

Tuwopa Yaxaxa is a reading room for the unglamorous technical decisions behind a website redesign: URL structure, redirect logic, staging environments, and what happens to organic traffic when those steps get skipped. We write about the mechanics. We do not sell migration services.

Read the framework articles Our editorial lens
Two people reviewing a URL structure and sitemap plan spread across a desk before a website migration

What actually breaks during a redesign?

Most site migrations do not fail because of design choices. They fail in the plumbing. A new CMS, a new folder structure, a rebrand that changes every slug at once. The visible layer looks better. The invisible layer, the one search engines depend on, quietly loses its map.

Changing a URL without a redirect is a bit like moving house without telling the post office. The new place might be nicer. But every letter still gets sent to an address that no longer answers, and nobody forwards it for you. Search engines behave the same way. They keep trying the old address until something tells them, clearly and permanently, where the content went.

Four things that go wrong, and how they get caught early

Building a redirect map before touching anything

A redirect map is a spreadsheet, nothing more exotic than that. One column lists every existing indexed URL. A second column lists its destination on the new site. Built before development starts, it becomes the single source of truth for developers, not an afterthought squeezed in during launch week.

Skipping this step means someone is improvising redirect rules the night before launch, usually from memory. That rarely ends well for either the users or the crawlers.

A small team reviewing a staging website environment on a laptop before pushing changes live

What a staging environment actually protects

A staging environment is a private copy of the site where changes are tested before the public, and search engines, ever see them. Skipping it does not save time. It just moves the debugging into production, in front of an audience.

Free tools for watching rankings during a move

  • Google Search Console coverage and performance reports
  • Bing Webmaster Tools for a second crawler's perspective
  • Server log sampling to see what bots actually request
  • Manual SERP spot checks for priority queries
  • The Wayback Machine, to confirm what the old site looked like

Post-mortems, from public data

No invented numbers

Case studies here are built from publicly available reports, forum threads, and documented crawl behavior, never from private client data. If a number cannot be sourced, it does not appear.

301s, canonicals, and the difference that matters

A 301 redirect tells search engines a page moved permanently and to pass its signals along. A canonical tag says something closer to "this page is a copy, credit the original." Confusing the two during a migration is a common, quiet cause of ranking loss that takes weeks to notice.

Recent framework articles

Long-form, technical, written for the person actually doing the migration work, not the person selling it.

Redirect mapping

Building a redirect map in a spreadsheet, column by column

What to include, what to skip, and why the sheet should exist before a single line of new code is written.

Read the framework
Staging & QA

Why skipping a staging environment costs traffic later

The hidden connection between "we tested it live" and the traffic graph that drops two weeks after launch.

Read the framework
Rank monitoring

Watching visibility during a migration with free tools only

A practical schedule for checking Search Console, server logs, and manual queries in the days after launch.

Read the framework
Post-mortems

Reading a public migration failure like a technical report

How to separate coincidence from causation when a public case study says traffic fell after a redesign.

Read the framework
A whiteboard covered with a traffic drop timeline and crawl error notes during a migration post-mortem review

Learning from migrations that already happened

Some of the most useful material on this subject was never written as a lesson. It was written as a complaint on a forum, a thread on a marketing subreddit, or a case study buried in a conference talk. Post-mortems here pull from that kind of public record and lay the timeline out plainly: what changed, what broke, and roughly how long recovery took according to what was reported.

None of it is presented as prediction. A migration that went wrong for one site is not a guarantee anything similar will happen elsewhere. It is a pattern worth recognizing, nothing more certain than that.

See framework articles

Planning a redesign for your own site?

The For Content Publishers section is written for the person who owns the content, not the agency pitching the rebuild. It covers the questions worth asking a developer before launch and a monitoring cadence for the weeks after.

Open the publisher guide

Reach the editorial team

Questions about an article, a correction, or a source? These are the channels we check.

Office

6100 City Ave Ste 417
Philadelphia, PA

Phone

+1 215-307-3939

Email

[email protected]

Editorial hours

Monday to Friday
9:00 to 17:00 ET