Content restructuring

A restructure is a big decision. It changes where pages live, what they are called and sometimes whether they exist at all. Done carefully, it removes accumulated duplication and leaves a site that is easier to use and to maintain. Done carelessly, it breaks bookmarks, external links and search listings, and staff may field questions such as "where did that page go?" This service plans the change so the benefits arrive without the breakage.

When a restructure makes sense

• You are moving to a new content system or a new design, and every page will be touched anyway.
• Two or more websites are merging after an organisational change.
• An audit has shown that the current grouping no longer matches what visitors come to do.
• The site has grown to the point where nobody can say how many pages it holds or who owns them.

What the plan covers

Inventory and decisions. Every page in the current site, with a decision: keep as is, keep and edit, merge into another page, move to a new section, or retire. Each decision records a reason so it can be reviewed by the page owner.

New structure. The target sitemap, with labels and addresses. If you do not have one yet, we build it as part of this work, using the same method as sitemap planning.

Redirect map. For every old address that will change or disappear, the new address it should send people to. Google's site move guidance says each old URL should point to its best new destination, not to a generic page such as the home page, and recommends "HTTP permanent redirects if possible, such as 301 and 308".

Retirement rules. What happens to content you remove. Some pages should redirect to a close replacement; some should return a "gone" response because no replacement exists; some need archiving for legal reasons.

Link updates. A list of internal links that point to old addresses, so they can be updated rather than left to rely on redirects.

Sequence. The order of work, so content owners know when to review, writers know when to rewrite and developers know when to apply the redirects.

How the work runs

1. Inventory. Crawl the current site and combine the results with analytics and the content system's own page list.
2. Decide. Work with page owners on keep, merge, move and retire decisions. We prepare recommendations; owners confirm.
3. Structure. Finalise the target sitemap and addresses.
4. Map. Build the redirect map, one row per old address.
5. Check. Test the map for chains (one redirect pointing to another) and loops, and for old addresses that send people to an unrelated page.
6. Launch support. A checklist for launch day and the weeks after: submit the new sitemap, monitor errors and fix stragglers.

What you receive

• A decisions spreadsheet covering every current page.
• The target sitemap and URL rules.
• A redirect map in a format your developer can load into the server or content system.
• A list of internal links to update.
• A launch checklist based on Google's site move guidance, including when to submit the new sitemap in Search Console.

Being realistic about search visibility

Google warns that visibility in Search "may fluctuate temporarily" during a move. A careful redirect map, updated internal links and a new sitemap reduce the risk, but nobody can guarantee traffic will stay the same. Anyone who promises that is guessing. What we can promise is that every old address you give us has a planned destination.

Merging pages well

Merging is the decision that needs particular care. Two pages that cover the same topic may not say the same thing: one may have the current fee, the other the clearer explanation. The plan records which page survives, which parts of the other page move into it, and which facts need checking by the owner before launch. The merged page then takes the stronger address, and the other address redirects to it. Where the two pages served different audiences, the merged page may need a short section for each, rather than a compromise that suits neither.

What we need from you

• Access to the content system's page list or an export.
• Read-only analytics and search console access, if available.
• Named owners for each section who can confirm decisions.
• Your developer's preferred redirect format.

Related reading

The guide to restructuring without losing search traffic walks through the redirect and launch steps in more detail. If you are not yet sure a restructure is needed, start with an information architecture audit.

Questions about this topic

Do we have to restructure before changing platforms?

You do not have to, but a platform move is the cheapest moment to do it. Every page is being touched anyway, and moving content you will later delete costs time.

How long should redirects stay in place?

Google's guidance is to leave them in place for at least a year, and longer where you can. We suggest treating them as permanent unless there is a strong reason to remove them.

Will our search traffic drop after a restructure?

Google says visibility may fluctuate temporarily during a move. A complete redirect map, updated internal links and a new sitemap reduce the risk, but no one can promise traffic will hold steady.

Sources checked 4 November 2026 for content restructuring

1. Site moves, Google
2. Sitemaps, Google
3. Links, Google