Keeping the Addresses When You Rebuild

What an address actually is

It is the identifier that everything external points at.

Search engines have recorded it against a set of positions. Other sites have linked to it. Customers have bookmarked it. Your own printed material references it. An email you sent in 2018 contains it.

None of that belongs to your design. It attaches to the address, and it took years to accumulate.

Why rebuilds break them

Almost never deliberately. It happens as a side effect of building on a new platform.

The new system has its own conventions, so a page that was at one address is now at another with a different pattern.

Nobody decided to change them. The new platform had a default, the default was accepted, and four hundred addresses moved as a consequence of a setting nobody discussed.

This is worth raising explicitly with whoever is building the site, before anything is built, because afterwards it is a much larger conversation.

Export the list first

Before a single page of the new site exists, you want a complete list of what currently exists.

A crawl of the live site produces it in a few minutes. Your search console will also provide the addresses that actually receive visitors, which is a more useful ranking of what matters.

Keep both. The crawl tells you what exists; the traffic data tells you what would be missed.

Put them in a spreadsheet, because this becomes the redirect map later and you want it in a form you can annotate.

The default should be keep

The strongest position is that addresses do not change unless there is a specific reason.

Most platforms can be configured to reproduce an existing address pattern. It is a settings decision plus, occasionally, a small amount of work, and it is far cheaper than the alternative.

When somebody proposes a new address structure, the question to ask is what it buys. Frequently the answer is that it is tidier, which is not worth the cost of moving every address you own.

When an address genuinely has to change

• The page is being merged into another one.
• The page is being removed entirely.
• The old address contains something broken, such as a session code or a dead category.
• The structure genuinely misdescribes the content now.
• You are moving domains as well as rebuilding.

Those are legitimate. A new platform preferring a different pattern is not on the list.

Address hygiene worth fixing while you are there

If you are changing some addresses anyway, a few things are worth correcting.

Dates in the address of pages that are not news, which make ordinary content look stale.

Numbers and codes that mean something internally and nothing to a reader.

Very deep nesting, where a page sits five folders down for no reason a visitor would recognise.

And mixed conventions, where some addresses use one separator and others use another because two people built different sections.

Fix those deliberately, with redirects, rather than as a side effect.

A worked example

A wholesaler moved from one platform to another with about six hundred pages.

The build quote assumed the new platform's default address pattern, which would have changed every single one.

The crawl showed that roughly ninety pages accounted for almost all of the traffic, and about forty of those had links from other sites, including two trade publications and a manufacturer.

Reproducing the old pattern on the new platform took a developer under a day.

Of six hundred addresses, eleven changed: nine merged pages and two removals, each mapped to a specific destination.

The launch produced no measurable dip. A comparable rebuild the year before, at a business the same owner knew, had changed everything and taken about five months to recover.

What redirects do and do not do

A permanent redirect tells a browser and a search engine that a page has moved, and passes along most of what the old address had earned.

It works well and it is the correct tool. It is also not free.

Each redirect adds a small delay for anybody following the old link, chains of them compound that, and every one is a thing that has to survive future migrations and be maintained by somebody who understands why it exists.

So redirects are the right answer for addresses that must change, and not a reason to be relaxed about changing addresses that need not.

Keeping them is not only about search

The search argument is the one that gets made, and it is the smaller half.

Addresses appear in places you cannot update. Printed brochures, vehicle livery, a supplier's dealer listing, an industry directory, a customer's internal procurement document, an email signature at a company you sold to three years ago.

Those references do not get a redirect map. They either work or they produce a not-found page for somebody who was trying to reach you.

That is the more concrete cost and it lasts far longer than the search recovery does.

Test the map before the switch, not after

A redirect map is a list of intentions until somebody proves each line works.

The test is mechanical: take the exported list of old addresses, request every one against the new site, and record what each returns.

You are looking for three faults. Addresses that return a not-found response, meaning a redirect was never written. Addresses that land somewhere unhelpful, usually the homepage, because a lazy catch-all rule was used instead of specific mappings. And chains, where one redirect points at another that points at a third.

On a large site this has to be scripted or run through a crawler, since nobody checks six hundred addresses by hand reliably.

Run it against the staging site before launch, then run the identical test again an hour after the switch, because a rule that worked in one environment does not always survive the move to the other.

The counter-case

Occasionally the existing addresses are genuinely not worth keeping.

A site built on a system that generated addresses full of query codes, a site that was never indexed, or a site so small and so new that nothing points at it yet.

In those cases the accumulated value is close to zero and preserving a bad structure to protect nothing is the wrong trade.

But that judgement should follow the crawl and the traffic data rather than precede them, because businesses consistently underestimate what points at their older pages.

Before the build starts

1. Crawl the live site and export every address.
2. Pull the traffic data and sort by visits.
3. Check which pages have links from other sites.
4. Tell the builder addresses are preserved by default.
5. List the exceptions and why each one changes.
6. Map every exception to a specific destination.

All six happen before design, not after, which is the part that gets this wrong most often.

Deciding which pages survive at all is covered in pages nobody has opened in a year.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.