How to redesign a website without losing SEO: what moving 172 URLs taught us
You redesign a website without losing SEO by treating every existing URL as an asset: list them all, keep the paths that can stay, redirect each one that changes with a single permanent redirect, and carry the titles, descriptions and headings across unchanged. Then you check all of it by machine before the domain moves. This is how we did it for a site of 172 pages in two languages, and what the checks caught.
The project
In 2026 we moved a bilingual photography and film studio off Squarespace onto a custom Next.js site. The client is not named here at their request, so there are no screenshots. The numbers are from the project’s own records.
- 172live pages, in two languages
- 224URLs Google knew about
- 57permanent redirects at launch
- 176 / 176rows passed the launch check
1. List every URL, then ask Google what it knows
A crawl of the old site found 172 live pages, 86 in each language, all returning a normal response. That list felt complete. It was not.
Search Console knew 224 URLs for the same domain. The 52 extras were addresses the site had never linked to, or no longer did, and Google still held every one of them.
| What they were | How many | What we did |
|---|---|---|
| Parameter and system addresses | About 25 | Left alone, on purpose |
| Targets of older redirects | About 14 | Redirected to the live page |
| Category addresses the platform generated | 8 | Redirected to the clean category page |
| Duplicates and phantoms | 4 | Redirected or dropped |
| A real page missing from the list | 1 | Added to the inventory |
2. Keep the URLs that can stay
The safest redirect is the one you never need. The policy was one to one: every page kept its exact path on the new site, language prefix and slug included. All 172 did. Only four pages were renamed, each at the client’s request on or after launch day, and each got a permanent redirect with the rename.
This costs something in the build. Slugs differ between the two languages and follow no rule, so they are stored per page, never generated. That is cheaper than recovering a ranking.
3. Write the redirect map, and test it with the awkward addresses
The site went live with 57 redirect rules. Every one is a permanent (301) redirect, a single hop, to a page that answers. When a target was later renamed, the rules pointing at it were re-pointed, so a chain never formed.
The check that mattered was on the addresses nobody would choose. The old platform exposed category URLs containing capital letters, spaces, an ampersand and non-Latin characters. Four of those were silently dropped by a filter in our own redirect code and returned "not found" on staging. Google knew all four. The fix was to percent-encode every source address, and to add a second rule for the encoded ampersand.
4. Find out what the old platform will not give you
Squarespace’s export is an XML file of blog posts and basic page text. It holds no galleries, no video blocks, no images and no layout. Everything else had to be collected another way.
| What | Where it came from |
|---|---|
| Titles, descriptions, headings, canonicals | A crawl of the live site |
| Body copy | A script that fetched and extracted each page |
| Service pages | Captured by hand |
| Language pairs | A hand-kept footer switcher; the old site had no hreflang at all |
| Image descriptions | Written fresh, in both languages |
| Search engine verification | Recovered from the old home page’s HTML |
| Email records | Copied by hand from the DNS panel |
The crawl also showed what not to carry across. Of the 172 old pages, 130 had two main headings instead of one. The platform also set headings in capitals with a style rule, so the extracted text had to be checked against the real, accented spelling.
5. Check all of it by machine before the domain moves
We wrote a script that walks the whole inventory and compares the new site against the record of the old one. It does not sample. It checks every row.
- The title, the description and the main heading of every page, compared exactly.
- The canonical address, the language annotations and the structured data.
- Every redirect: one hop, permanent, landing on a live page.
- The sitemap: every entry is a real page in the inventory.
- That "do not index" is on for staging and off for the real domain.
On the live domain, the night of the move, it passed 176 of 176 rows with no failures. That number is only interesting because of what the same script found in the days before.
| What it found | Why it mattered |
|---|---|
| 181 fields on 85 pages edited in the CMS without a record | The site no longer matched what was agreed to be migrated |
| One page returning "not found" | Its row carried the other language’s slug |
| The second-language home page serving an English title | The wrong page would have been indexed for that language |
| Two posts with each other’s title and heading | The mistake was live on the old site and had been copied faithfully |
6. Make the move reversible
The move itself was one change: the domain’s nameservers. The old site was left running and untouched, so going back was the same single change in reverse. The night before, the email records were copied to the new DNS and two were added that had never existed (SPF and DMARC), because a test message from the new contact form had landed in spam.
What happened to indexing
Before the move, Google had indexed 135 of the 172 pages. Nine days after it, the count was 143.
That is where our record ends. We do not hold traffic or ranking figures for the months after, so we are not going to print any. What we can say is what the process is built to protect: the addresses Google knows keep answering, with the same titles and headings, from the first minute.
The checklist
- Crawl the old site and export every URL with its title, description and main heading.
- Export the URLs Search Console knows and compare the two lists.
- Keep every path you can. Decide the rest, one by one.
- Write a single-hop permanent redirect for each address that changes.
- Test the redirects with the awkward addresses: spaces, capitals, symbols, other alphabets.
- Carry the titles, descriptions and headings across unchanged. Improve them after the move, not during it.
- Check every row by machine on staging, then again on the live domain.
- Move the domain with one reversible change, and keep the old site running.
- Submit the new sitemap, then watch indexing for a month.
- Keep the redirect map for as long as the site exists.
The same method scales down to a site of a few pages. The list is shorter; the steps do not change. Velricon is a redesign of that size.
