Redesigning a Roofing Website Without Losing the Rankings You Have

A roofing website keeps its rankings through a redesign when every URL that had value still resolves to a page that says at least as much about the same subject. Everything that goes wrong in a migration is a variation on failing one half of that sentence, and almost all of it is preventable with an inventory taken before anybody designs anything.

Why roofing sites lose traffic in a redesign

Almost never because the design changed. Traffic is lost because the site’s structure changed underneath the design, and nobody reconciled the two.

The typical story runs like this. A roofing company has a site that grew over six years and now has forty pages, including a dozen town pages somebody added at various points and a set of service pages with awkward URLs. A new site is designed around eight clean pages with a beautiful gallery. It launches. Two months later the phone is noticeably quieter and nobody can say why.

What happened is that thirty-two pages stopped existing. Some of them were doing nothing. Several of them were the reason the company appeared for a service in a specific town, and their absence is invisible on the new site because the new site does not know they existed.

Step one: the inventory, before anything else

Before a wireframe, before a color, list every URL the current site has and what each one is worth. This is the document the entire migration is built on.

Pull the list from several sources, because no single one is complete: the existing sitemap, a crawl of the site, the pages receiving impressions and clicks in Search Console, the pages with traffic in analytics, and the pages with inbound links. Merge them into one sheet.

Against each URL, record what it is about, what it earns in impressions and clicks, whether anything external links to it, and what its fate will be in the new site. That last column has exactly three legal values: kept at the same URL, moved to a new URL that is named, or retired with a named redirect target.

There is no fourth value. A URL with a blank fate column is a page about to be lost silently, and the whole point of the inventory is to make that impossible.

What tends to surface

Two things usually come out of this exercise that nobody expected. The first is a handful of pages producing real search impressions that nobody on the team knew were there, often old town pages or a post written years ago that answers a question people still ask. Those are the ones to protect most carefully.

The second is a long tail of genuinely dead pages: duplicated drafts, an old promotion, three versions of the same service. Retiring those is fine and healthy. Retiring them deliberately, with a redirect to the page that replaces them, is the difference between tidying and losing.

Step two: decide about URLs honestly

Google’s guidance on site moves with URL changes describes what is involved when addresses change, and the clear implication is that a move is a project rather than a side effect.

So the first question is whether the URLs need to change at all. Frequently they do not. A site can be completely rebuilt, with new templates, new copy and a new design, on the same URLs, and that is by a wide margin the lowest-risk version of this work.

Reasons that justify changing a URL: it contains a query string or a date that no longer makes sense, it sits under a path that contradicts the new structure, or it is genuinely unreadable. Reasons that do not: somebody prefers the new pattern aesthetically, or a tool suggested a keyword should appear in the slug.

Where URLs do change, change them all at once, in the same release, rather than in waves. Two migrations cost more than twice one migration, because each one re-opens the same instability.

Step three: map the redirects one to one

Every old URL that is not being kept needs a redirect, and Google’s documentation on redirects covers the types and how they are treated. A permanent redirect is the right instrument for a permanent move.

Three rules make the difference between a mapping that works and one that looks complete and is not.

One old URL, one new URL, chosen on meaning. The new target is the page that most closely answers what the old page answered. Not the category page, not the closest match alphabetically.

Never blanket-redirect to the home page. It is the most common shortcut and it wastes everything the old page had. To a search engine a mass redirect of many pages to one is close to a signal that those pages no longer exist, and to a visitor it is a dead end: they clicked a link about roof repair in their town and landed on a generic front page with no idea where to go next.

No chains. Old A redirecting to old B redirecting to new C is a chain, and chains accumulate quietly through successive site changes. Point A at C directly.

Test the map before launch, not after

Take the full list of old URLs and request every one against the new site in a staging environment. Every single one should return either the page itself or a redirect to a real, correct page, and nothing should return a not-found or a chain. This is a script somebody runs in a minute, and it is the single highest-value hour in the whole project.

Step four: content parity

A redirect preserves the address. It does not preserve the reason a page ranked.

If the old page had eight hundred words about roof repair in a named town, including the permit situation and the local housing stock, and the new page has a headline, a photograph and a form, the redirect is technically correct and the outcome is still a loss. The page that arrives is a weaker answer than the page that left.

This is where roofing redesigns most often go wrong in a way that is hard to argue against in the room, because the new page looks so much better. It is worth being explicit during the design phase: any page carrying search traffic is a page whose substance has to survive, and the design’s job is to present that substance better rather than to have less of it.

The practical mechanism is simple. For every page in the inventory earning impressions, list the questions the old page answers. The new page has to answer all of them. It can answer them in a better order, in better language, with better structure. It cannot skip them.

Step five: the technical checks around launch

Two failures here are common enough that they deserve naming individually, and both are absolute rather than gradual.

The staging site must be blocked, and the live site must not be

Staging environments should be blocked from indexing while they exist, using the mechanisms in Google’s documentation on blocking indexing. A staging copy that gets indexed competes with the real site and confuses everything.

The reverse failure is worse and more common: a site launches with the staging block still in place, and the entire site quietly drops out of search over the following weeks. Nothing on the site looks wrong. This is the check to do on launch day, then again the next morning.

Canonicals must point at the live, final URL

Canonical tags left pointing at staging URLs, or at the old domain, are a way of asking a search engine to prefer a page that does not exist. Google’s canonicalization documentation covers how the signal is interpreted. Every page should declare itself as the canonical version of itself, with the final protocol, the final domain and the final path.

The sitemap must describe the new site

Submit an updated sitemap on launch containing the new URLs. Google’s sitemaps documentation covers the format and submission. During a move it is also reasonable to leave the old sitemap available briefly so the redirected URLs are recrawled and the moves are discovered promptly.

Everything else that quietly breaks

Analytics tracking removed in the rebuild. Form notifications pointing at a former employee’s address. The phone number in the header hardcoded to an old tracking number. A robots file copied from staging. Each one of these is invisible on a beautiful new site and each one costs real money, so they belong on a launch checklist rather than in somebody’s memory.

Changing domain at the same time

Rebuilding and moving to a new domain in one release is possible and it doubles the number of things that can go wrong, so it deserves a deliberate decision rather than drifting into it because somebody bought a better name.

If the domain is genuinely changing, the rules above still hold and two more are added. Every old URL on the old domain redirects to its exact equivalent on the new one, path for path, and the old domain has to stay registered and pointed for years rather than months. Letting it lapse two years later severs every inbound link the business ever earned, and those links are the slowest asset to rebuild.

Use the change of address tool in Search Console for a domain move, verify both properties, and expect the process to take time. What you should not do is run the two sites in parallel as a hedge. Two live copies of the same content competing with each other is the worst of both options, and it delays the point at which the new domain is treated as the real one.

If the business case for the new domain is weak, keeping the existing one is almost always the better trade. A rebuild on the current domain carries a fraction of the risk, and domain names matter far less to how a roofing company ranks than the pages sitting on them.

Who has to be in the room

The failure mode in most roofing website rebuilds is organisational rather than technical. The designer does not know which pages earn impressions. The owner does not know that thirty pages are about to disappear. The person who knows both is usually nobody.

Three things fix that, and none of them cost anything.

The inventory is a shared document, not a technical artefact. The owner should be able to read it and see, page by page, what is being kept, moved and retired. That is the moment to catch a town page somebody forgot about, and it is much cheaper to catch it in a spreadsheet than after launch.

One person owns the redirect map. Not the designer, not the developer, not the marketing contractor who left in spring. One named person who signs off that every old URL has a destination and that the test run came back clean.

Launch day has a checklist with names against each item. Unblock the live site, confirm the canonicals, submit the sitemap, submit a form and confirm it arrives, call the number in the header, check analytics is recording. Six items, fifteen minutes, and they catch the failures that otherwise take two months to surface.

Step six: watch the right things afterwards

Some fluctuation while a move is processed is expected. Panic in week one causes more damage than the migration, because it produces reactive changes that add new variables.

What to watch, weekly, for the first two months:

• Coverage and indexing. Are the new URLs being indexed, and is the count roughly what it should be.
• Not-found errors. Any old URL returning a 404 is a mapping miss, and it should be fixed the day it appears.
• Impressions and clicks on the pages that mattered. Compare against the inventory, page by page, not as a site total. A site total hides a town page that lost everything while the home page gained.
• Form submissions and calls. The business metric, and the one that actually decides whether this went well.

If a specific page has lost position and its redirect is correct, the answer is almost always content parity, and the fix is restoring what was cut rather than adding new pages.

The pages roofing companies drop most often

From enough migrations, the same page types go missing, and they are consistently the ones worth most.

Town and service area pages. The single biggest source of loss. They are often ugly, often written by whoever was cheapest at the time, and almost always the reason the company appears for a service in a specific place. A new design that consolidates twelve of them into one services page has, from a search point of view, deleted twelve pages.

Old blog posts that still rank. Somebody wrote a piece on hail damage claims four years ago, it reads a little dated, and it is quietly the third most visited page on the site. Rewrite it if it needs rewriting. Do not remove it.

Individual service pages folded into one page with tabs. Tabs look tidy and they collapse several ranking pages into one URL. Where the tabbed content is all present in the HTML this is survivable; where each tab loads on demand, the content effectively no longer exists for a crawler.

Location and contact pages for a second branch. Frequently dropped in a consolidation, and they often carry local relevance the rest of the site does not.

Anything with a slightly embarrassing URL. A page at a URL with a number in it, or a leftover path from an older platform, often gets quietly abandoned rather than redirected, precisely because nobody wants to carry it forward.

The pattern is that the pages most likely to be cut are the ones that look worst, and page quality as a designer judges it has very little correlation with page value as the business experiences it. That is exactly why the decision has to be made from the inventory rather than from a look at the site.

When a rebuild is the right call anyway

None of the above is an argument against rebuilding. A roofing site that is slow, cannot be updated without a developer, has one page for the whole county, and loses leads at a nine-field form is costing more every month than the rebuild will.

It is an argument for rebuilding with the inventory in hand, so the new site inherits everything the old one earned instead of starting again from nothing. Done that way, a migration is usually flat for a few weeks and then better than before, because the new site is faster, has more pages that deserve to rank, and converts more of the people who arrive.

Done without the inventory, it is a coin flip where the downside is a season of lost work, and the worst part is the delay in noticing. Search traffic decays over weeks rather than dropping overnight, so by the time the phone is obviously quieter, the launch is three months back and the connection is no longer obvious to anyone.