The checklist in one line: inventory what earns, protect those pages, map one-hop redirects, keep tracking continuous, and verify everything in launch week — in that order. An HVAC website redesign is one of the few marketing projects that can quietly destroy value while looking like progress. The new site launches, everyone admires it, and three weeks later the phone is slower — because redirects were skipped, a converting page was “simplified” away, or the tracking that proved what worked never made it across. This checklist is the boring insurance against that outcome. The production approach it reflects lives on the HVAC website design page.
What should you inventory before touching anything?
Before a single mockup, list what the current site actually does: every URL that receives search traffic, every page that produces calls or form submissions, every phone number and form endpoint in use, and every place the site is referenced elsewhere — the Google Business Profile if one exists, directories, invoices, truck decals. The old site is a working system, however dated it looks, and you cannot preserve what you have not written down. A one-hour inventory beats a month of “why did February slow down” forensics. Keep the export: it becomes the acceptance list the new site is checked against, page by page, before anything goes live.
Which pages are actually earning, and how do you find out?
Traffic is not the measure; outcomes are. A page with forty visits a month that produces six calls outranks a blog post with four hundred visits and none. Search Console shows which URLs earn impressions and clicks; call records and form logs show which pages sit at the start of real jobs. Mark every earner as protected: its content survives the redesign substantially intact, its URL either stays identical or gets a permanent redirect, and its conversion elements — the tap-to-call, the short form — are rebuilt before anything decorative. The redesigns that go wrong almost always go wrong here, by treating earning pages as raw material instead of assets.
What do redirects need to look like?
Every old URL that changes must answer with a single permanent redirect to its one best successor — not to the homepage, not through a chain, not a soft 404. Map them one to one before launch and test the list mechanically after; a spreadsheet and an afternoon covers a site of typical contractor size. Redirect chains and mass homepage redirects are how accumulated search equity leaks away in the weeks after a relaunch, and the leak is invisible until the ranking reports arrive. If the old site had a page for every service and the new one consolidates, redirect each retired page to the specific section that replaced it, and keep the mapping file in the repository so the next redesign inherits it.
How do you keep measurement continuous through the switch?
Whatever proves the site works — call tracking, form notifications, analytics events — must be live on the new site from its first minute, measuring the same things under the same names. A gap in measurement during the transition means the before/after comparison everyone will ask for is guesswork. Rebuild the tracking on the staging site, verify each event fires, and only then switch traffic. The measurement contract is a useful template for deciding what counts: observable states with owners, and no claiming outcomes the data cannot support. A redesign that cannot show its effect in confirmed events six weeks later was a decoration project, whatever it cost.
What does content parity actually require?
Parity means the new site answers every question the old site answered, not that it copies the old pages. The practical method: from the inventory, extract the questions each earning page answered — service scope, brands handled, financing, service area, hours, the process from call to completed job — and check the new information architecture against that question list rather than against the old page list. Consolidation is fine; loss is not. The classic redesign injury is the “simplification” that deletes the page answering the exact long-tail query that brought in booked jobs, because that page looked minor in a traffic report. Word count is a crude but useful tripwire here: when a 1,200-word service page becomes a 200-word card grid, something that was ranking has probably been amputated, and the ranking will follow it out. Keep a parity table — old URL, questions answered, where each answer now lives — and make it part of the launch sign-off.
When should you schedule the switch, and what gets frozen?
Cut over in your slow season, never in the weeks before peak. A redesign carries a settling period — redirects propagating, search engines recrawling, small bugs surfacing — and that turbulence is cheap in the shoulder months and expensive in July. Pick a low-traffic day and hour, have the person who can fix DNS and hosting actually reachable, and keep the old site restorable for a rollback window measured in weeks, not hours. From the moment the redirect map is written until launch, freeze URL decisions: every late renaming quietly invalidates a mapping row, and launch-eve creativity is how a tested plan becomes an untested one. Batch any post-launch content ideas for the week after. The redesigns that go smoothly are boringly sequenced: inventory, build, parity check, tracking rehearsal, freeze, switch, verify — with the exciting decisions all made early, where they are cheap.
What belongs in the launch-week checklist?
Launch is a verification exercise, not a celebration. The list is mechanical: every protected page renders and converts on a real phone; every redirect from the mapping file answers correctly; forms deliver to a monitored inbox; the tap-to-call number is the business number; the sitemap reflects the new URL set and has been resubmitted; page speed on the money pages is within budget on mobile; and the missed-call path — if one runs, like the text-back workflow — still receives events from the new site’s numbers. Hold one person accountable for the list rather than assuming the agency covered it. Most of these checks take minutes; skipping any of them has a failure mode measured in weeks.
What should you expect rankings to do after launch?
Even a clean migration usually produces a few weeks of movement while search engines recrawl the new structure, re-evaluate consolidated pages, and follow the redirect map. Expect wobble; react to trend. The discipline is to decide in advance which numbers constitute an alarm — a protected page losing its ranking for the query that feeds it real calls, indexed-page counts dropping past the consolidation you planned, or redirect errors appearing in Search Console — and which are noise, like day-to-day position shuffling on long-tail queries. Keep the pre-launch baseline export so the comparison is against data rather than memory. If a protected page is still underwater after the settling period, diagnose in order: is the redirect right, is the content parity real, is the page actually in the index? Those three cover most genuine regressions. What you should not do is start re-rewriting pages in week two — churning content during the recrawl extends the turbulence you are trying to read through.
Who does what when an agency is involved?
Most redesign failures are assignment failures. The agency assumes the owner is watching the redirect map; the owner assumes that is what agencies are for; nobody owns it, and it half-ships. The fix is a one-page responsibility list agreed before the build starts: who produces the URL inventory, who marks the protected pages, who writes and tests the redirect map, who rebuilds and verifies tracking, who runs the launch-week checklist, and who watches the post-launch numbers against the baseline. Every row has one name, and the owner’s name belongs on the rows that require business knowledge — which pages earn, which questions customers actually ask — because no agency knows that from outside. Put the checklist in the contract if the relationship is new. A competent shop will recognize the list and welcome it; a shop that waves it off as unnecessary has told you exactly how your migration will be handled.
When is a redesign the wrong move entirely?
Sometimes the honest audit says the current site’s bones are fine and the real problems are three slow templates, an unclear service page, and no after-hours answer. Fixing those is cheaper and faster than a rebuild, and carries none of the migration risk this checklist exists to manage. A rebuild earns its risk when the foundation genuinely blocks the work — unmaintainable tooling, a mobile experience beyond patching, information architecture that confuses even staff. The conversion-paths note is the sharper first question: if the three paths that matter can be fixed on the current site, start there. And whichever route you take, judge it the same way — by trust the visitor can verify and outcomes the records can confirm, not by how the launch screenshots look.