In short: keep the content that already brings you visits, don't change the URLs that work, and redirect the ones that do change to their new address with a permanent (301) redirect. On launch day, submit the new sitemap in Search Console and keep an eye on errors over the following weeks.
1. Before you touch anything, take inventory
The most expensive mistake in a redesign is finding out afterwards which pages were bringing in visits. Before you design anything, list every URL on your current website and which ones get traffic from Google:
- Your sitemap (usually at
yourdomain.com/sitemap.xml): the list of pages your website declares. - Search Console → Performance → Pages: the pages that get clicks from Google. Look at the last 12 months so you don't miss seasonal pages.
- Your analytics, if you have them: the pages people land on.
That gives you the list of what you can't afford to lose.
2. Decide which URLs stay and which change
If a URL works, the best decision is almost always not to change it. When it has to change (because you're reorganizing the website or the URL was ugly), write it down in a two-column table: old URL and new URL. Google calls this URL mapping, and everything else builds on it.
| Old URL | New URL |
|---|---|
/index.php?page=menu | /menu/ |
/design-services.html | /services/web-design/ |
/contact/ | /contact/ (unchanged) |
Pages that disappear with no replacement should redirect to the closest match, not all to the home page.
3. Redirect with 301s, one by one
Every URL that changes needs a permanent server-side redirect (status code 301 or 308) to its new address. That way Google understands the page has moved and transfers its signals to the new one.
- Avoid chains (A → B → C). Google recommends keeping hops to a minimum: ideally no more than 3 and, in any case, fewer than 5.
- Keep the redirects in place for at least one year, as Google advises. The simplest option is to never remove them.
- Don't use temporary redirects (302) for a permanent change.
4. Don't cut the content that ranks
A prettier new website with half the text usually loses visits. If a page ranked for what it explained, that text has to stay on the new one, in the HTML, even if you present it better. Animations sit on top of the text: Google reads it even if it doesn't run the animation.
5. Check the technical side of the new website before launch
- Every page with its own
titleand description, and acanonicaltag pointing to itself. - Internal links (menu, footer and body text) already pointing to the new URLs, not to the old ones through redirects.
- A new sitemap with only the new URLs.
- Make sure the staging setup doesn't slip through: if it had
noindexor arobots.txtblocking everything, remove it at launch. - The structured data you had (local business, products, menu) on the new website too.
6. If you're also changing domains
If you're moving from yoursite.com to yoursite.es, do everything above and also use the Change of Address tool in Search Console. It only works for domain or subdomain changes, not for moving from http to https or for adding or removing www.
7. Launch day and the weeks after
- Submit the new sitemap in Search Console.
- Manually check ten important old URLs: each one has to lead, in a single hop, to its new page.
- Check the pages report in Search Console for any 404 errors or excluded pages you didn't expect.
- Be patient: it's normal for rankings to shift a little. According to Google, for a medium-sized website it can take a few weeks or more before it shows the new URLs.
The short list
- Inventory of URLs and of the pages that get clicks.
- Old URL → new URL table.
- 301 redirects one by one, with no chains.
- The text that ranks, on the new website too.
- Canonicals, internal links, sitemap and structured data checked.
- Change of Address in Search Console, if you're changing domains.
- Sitemap submitted and errors monitored for a few weeks.