Contractor Website Redesign: How to Plan a Safe Migration

Separate the design change from a platform or domain move

First write down what is changing: visual layout, content, content-management system, hosting, domain, URL structure or analytics. Changing several at once makes a failure harder to trace. If possible, keep stable URLs and avoid changing the domain while also rebuilding page hierarchy.

For each change, record an owner and a verification step. A new theme can affect forms; a new host can affect redirects and SSL; a domain move affects every canonical and external link. Google’s migration guidance distinguishes moves with and without URL changes because the checks differ.

Inventory pages and their business role

Export the current URL list from the sitemap, analytics and Search Console. Mark service pages, industry pages, location information, resource guides, campaign landing pages and legal pages. Note pages that receive inquiries, backlinks or meaningful impressions. Do not rely on a menu inventory alone; older but useful URLs may not be in navigation.

For each URL, decide whether to keep it, improve it, merge it into a genuinely equivalent page, or retire it. A page that is no longer relevant should not automatically redirect to the home page. Map it to a destination that satisfies the same visitor need or return an appropriate not-found state.

Build and review a URL mapping

Create a two-column mapping of old URL to final URL and include a reason for every removal or relocation. Check for path, trailing-slash and case differences. For unchanged URLs, explicitly note that the page remains at the same path. This becomes the acceptance checklist for both redirects and internal links.

When URLs change, Google recommends permanent server-side redirects where possible. A redirect should lead directly to the closest relevant destination and avoid chains. Check final response and destination with a crawler or a direct request after launch, and keep the map so future staff understand the transition.

Protect content, metadata and measurement

Copy useful text, image descriptions, page titles, descriptions, structured data and canonical rules into a migration checklist. Confirm that the new production pages use the correct `https://parralax.agency/` canonicals. Test that no staging `noindex`, preview host or temporary canonical remains on public pages.

Preserve analytics tags, the current consent choice, campaign parameters and the established successful GHL form event. Compare test page views, CTA clicks and successful form submissions as separate signals. Never redefine a button click or article visit as a lead to make the migration report appear healthy.

Test the site before routing visitors

On the preview, test the home page, important service and industry pages, booking flow, legal links, phone links, forms, responsive navigation and search. Use an internal test process for any form connected to a CRM. Verify the thank-you state and event only after the form service confirms success.

Check a representative phone, tablet and desktop layout. Test images, cookies and the footer, then use a crawl to identify broken internal links and missing titles. Make sure the site is accessible without scripts for core content and that the sitemap lists only final canonical URLs.

Launch in a controlled order

Record the current versions of key pages, analytics and sitemap before launch. Coordinate DNS and host changes with the person responsible for the domain, then check HTTPS, redirects and a few critical routes immediately after cutover. The office should know where new form submissions will appear and who will test the handoff.

Monitor the site’s error logs, Search Console pages and real inquiry path. Search systems need time to recrawl changes; a temporary change in reports is not proof of a permanent loss. Fix technical failures promptly, but avoid repeatedly changing URL patterns while the move is being processed.

Use this migration acceptance checklist

• Old and final URLs mapped with a reason for removals.
• Relevant permanent redirects point directly to the closest equivalent page.
• Final pages return successfully and use the production canonical.
• Sitemap contains only published canonical URLs.
• Forms, phone actions, consent and verified lead tracking work in the approved test flow.
• Internal links, images, metadata and legal pages are present.
• Desktop and mobile layouts have been reviewed, including the footer and booking path.
• A named owner will monitor issues after launch.

Know when not to migrate yet

Delay a redesign cutover if the team cannot identify the domain registrant, obtain access to the current host, reproduce the form flow or map important URLs. Resolve ownership and backup questions first. A new visual system cannot compensate for losing the contact records or site access needed to operate the company.

A migration is complete only as search engines and people move through the new paths successfully. Treat the launch as an operational change with a rollback plan, not just a design reveal.

Example URL map for a small contractor site

Suppose `/plumbing/` remains the main service page, `/water-heater/` is still useful and `/old-special/` contains an expired offer. Keep the first two paths if their intent is unchanged, update the water-heater page carefully, and retire the expired offer with a relevant replacement only if the replacement genuinely answers the same need. Do not route every removed page to `/` simply to avoid a 404.

For each changed URL, note the old address, new address, reason, redirect type and test result. This small ledger gives the developer, marketer and business owner one shared definition of what should happen after launch. It also makes later Search Console review easier: errors can be matched to a planned change instead of guessed at.

Schedule the move around people and systems

Choose a launch window when someone can test calls, forms, CRM notifications and email routing. Keep the old host or a restorable backup available according to the provider’s terms while the new site is verified. DNS changes can take time to resolve for different visitors, so document what the business should check and who can reverse a misconfiguration.

A post-launch review should include a handful of important URLs, the sitemap fetch, canonical output, redirects, tracking consent and the actual form-success path. Search reports may lag behind the change. Use direct technical checks for immediate failures, then monitor indexing and performance over subsequent weeks without repeatedly changing the same URL map.