GARAGE DOOR / WEBSITE REDESIGN
A garage door site that looks dated can still be the reason the phone rings. The pages that earn those calls, the service areas they cover and the links pointing at them are assets, and a redesign is where they are most at risk of being discarded.
Aevrion decides what to preserve before deciding what it should look like. The URL inventory and redirect map are built and reviewed before anything is designed.
01 / WHAT A REBUILD PUTS AT RISK
None of these is visible in a design mock-up, which is why they are the things a redesign loses. Each one exists before the project starts and has to survive it deliberately.
The pages that currently earn the phone calls — spring repair, opener repair, broken cable, off-track door, new installation. Each may have years of accumulated relevance that does not transfer to a new URL by itself.
Where a site has them, city and suburb pages can be its largest section — and they are an easy casualty of a redesign, because they look repetitive to whoever is reworking the visual layout.
Commercial door, rolling steel and gate operator pages serve a different buyer, on a longer cycle, at a value per enquiry that can exceed residential work. They are easy to lose in a rebuild because they draw less traffic than the emergency repair pages.
Supplier listings, association directories, chamber pages and local coverage point at specific URLs. Those references do not update when the site is rebuilt.
Installation galleries and before-and-after work are genuinely hard to reproduce. They are also the part of the site that could not have been produced by anyone else, which is what makes losing them expensive.
Review widgets and structured data are wired into templates. Where a rebuild replaces the template it can drop both silently, and the loss surfaces later as a changed listing rather than as an error.
The tap-to-call in the header, the quote form, the booking link and the emergency number all have measurable behaviour on the current site. A redesign that moves them is running an experiment whether or not it was described as one.
Analytics and Search Console history are how anyone judges later whether the rebuild helped. Losing that continuity removes the ability to answer the question at all.
Damage here is rarely dramatic on launch day. It can surface weeks later as a quiet decline in calls from pages nobody discussed — and by then, for that business, the cause is much harder to isolate.
02 / FIVE DECISIONS, ONE PER URL
This is the whole method. It is not complicated; it is simply done before the build rather than during it.
The URL and its content survive unchanged. Aevrion treats this as the default for any page that currently earns work, and it is the decision a redesign is most likely to skip.
Two or more thin pages become one better page, with the retired URLs redirected to it. Common where a site has separate pages for near-identical phrasings of the same service.
The content moves and the old URL points permanently at the new one. Every redirect is recorded with the reason it was chosen, so a later reviewer can tell a decision from an accident.
The page goes and does not come back. A truthful 404 is better than a redirect to an unrelated page, which is worse for the visitor and is treated as a soft error anyway.
The evidence does not support a decision yet. Recording this honestly is what stops an unexamined URL being quietly deleted under cover of a redesign.
Undecided is the one that matters most. A migration that produced no undecided URLs at all is worth questioning: either the evidence was unusually complete, or pages with thin evidence were deleted rather than flagged.
03 / THE GARAGE DOOR SURFACE SPECIFICALLY
A garage door site has a recognisable shape, and the parts most at risk are the parts a general redesign process treats as boilerplate.
Emergency repair and planned installation behave completely differently. The repair pages are found on a phone by somebody whose door will not close; the installation pages are browsed slowly, and may be revisited across several sessions and more than one device. A rebuild that optimises the whole site for one of those journeys degrades the other, and that degradation is invisible in aggregate traffic.
People search the failure, not the component: door off track, spring snapped, opener not responding, door reverses when closing. Where a site has accumulated pages for these symptoms, the inventory can show they earn more for that business than its owner expected — they read as unremarkable, which makes them early candidates for deletion in a tidy-up and among the last that should be.
The commercial section — rolling steel, dock equipment, gate operators — deserves its own decision rather than a shared one. Where it exists it can carry far less traffic than the residential repair pages and far more value per enquiry, which is exactly the combination a traffic-ranked tidy-up gets wrong.
A rebuilt site is also re-read by retrieval systems that judge it on different properties from a ranked result — a symptom page that answers one question plainly is easier to retrieve than a redesigned page that answers it in marketing abstractions. That distinction is set out in what changes when machines read your site.
04 / FIRST-PARTY EVIDENCE
This is not client work, and not a garage door project. It is the same method applied to Aevrion's own migration, published in full so the process can be checked rather than described.
Forty-two legacy URLs were inventoried. Twenty-six were permanently redirected, four were retired to a truthful 404, one was rebuilt, and eleven were left explicitly undecided because the evidence did not support a decision.
Publishing the undecided eleven is the part that matters. A clean migration is easy to describe after the fact; recording the URLs that could not be resolved is what makes the rest of the record checkable.
Aevrion publishes no garage door client results, because none exist to publish. This page describes a method and its first-party application — nothing about a rebuild performed for another company.
05 / THE MIGRATION SEQUENCE
Steps one to four happen before anything is designed. That ordering is the difference between a migration and a redesign that hopes for the best.
Crawl the current site and reconcile it against analytics, Search Console and the server's own list. A site that has changed platform at some point can carry URLs nobody remembers publishing, and those only appear in the reconciliation.
Impressions, clicks, entry behaviour and inbound links where the data exists. A decision made without evidence is a guess with a spreadsheet around it.
Each URL receives one of the five decisions above. Undecided is a permitted answer and is recorded as such.
The map is a deliverable in its own right, reviewed before anything is built, not assembled from memory during launch week.
Tap-to-call, quote form, booking link and emergency number are carried across deliberately. Where one is deliberately changed, it is changed as a stated decision rather than a side effect of a new layout.
Templates, content architecture, structured data and mobile behaviour — with the preservation decisions already settled, so the build is not making them implicitly.
Every redirect tested against the map. Metadata, canonicals and structured data verified on the new pages. Forms and call paths exercised on a real phone, not only in a desktop browser.
Crawling, indexation and redirect behaviour watched over the following weeks, with a defined owner. Damage of this kind can stay silent for a fortnight, and by then the cause is much harder to find.
06 / WHAT AEVRION DOES NOT PROMISE
“Zero SEO loss” is a common guarantee in this market. It is not one anybody can honestly make, because part of the outcome sits with how a search engine re-evaluates a changed site. What can be committed to is that every decision is recorded, so a change afterwards can be traced rather than debated.
07 / AFTER CUTOVER
A redirect map that was correct on paper and a site that renders correctly on launch day are not evidence that the migration worked.
Redirect behaviour against the map, crawl and indexation of the new URLs, error rates, and whether the conversion paths still function on a real phone. Each has a named owner for the weeks after launch rather than being everybody’s responsibility.
Some movement while a search engine re-crawls and re-evaluates is expected. The distinction that matters is between fluctuation that recovers and a specific page that stopped earning and did not come back — and only an inventory made beforehand lets anyone tell those apart for that business.
08 / DECISION SUPPORT
Not necessarily — but that is decided by the migration work rather than the design. When loss does happen it has a specific, avoidable cause: URLs changed without redirects, service-area pages removed as clutter, or metadata regenerated by a template. The inventory and redirect map exist to make each of those a decision somebody took deliberately rather than something that happened.
Not automatically, and not automatically not. Service-area pages vary enormously: some genuinely earn work, some are near-duplicates that were never useful. The point of attaching evidence to each URL before deciding is that this question gets answered per page instead of by a blanket rule applied by whoever is doing the build.
A design project starts with how the site should look. This starts with what the current site is already doing that a new one would need to keep doing. The redirect map is built before the templates, and preservation decisions are made before the build rather than discovered during launch week.
A site can be visually dated, difficult on a phone and still be earning calls from pages that rank. Those are separable problems. The inventory establishes which parts are producing something worth carrying forward, so the rebuild can be aggressive about the rest without being aggressive about everything.
No. It is a common promise in this market and it is not one anybody can honestly make, because part of the outcome sits outside the migration — including how a search engine re-evaluates a changed site. What Aevrion commits to is documenting every decision taken, so any change afterwards can be traced to a cause instead of argued about.
Yes. The inventory, evidence and redirect map are useful regardless of who builds the site, and they are the part a build brief is most likely to leave out. If the existing platform can carry the rebuild, keeping it removes a substantial risk from that project.
NEXT
Bring the current site and whatever measurement history exists — even partial. The inventory is more useful than a brief, and it is where the review starts.
Request a website migration review