What must survive the launch?
Make an inventory before changing the site. Include useful URLs, page titles, descriptions, content, images, structured data, search performance, and the journeys that create inquiries or bookings. Name who is responsible for each item.
Keep useful addresses where practical. When an address must change, map it to the relevant replacement and verify the permanent redirect. Sending unrelated old pages to the homepage does not preserve the experience the visitor expected.
Carry forward useful information. A polished page with less useful substance can answer fewer of the customer’s questions. Review revised copy against the purpose of the original page, then check that any structured data still describes what visitors can see.
Keep lead handling in the plan. Document the required fields, destination, confirmation screen, and notifications. Test the agreed journey after launch. A successful form animation alone does not establish that the business received the inquiry.
How do you check the live transition?
Verify old URLs and their destinations, internal links, canonicals, sitemap entries, and indexability. Confirm that staging restrictions have not accidentally reached public pages. Intentional exclusions, such as private or thank-you pages, need to remain intentional.
Check forms and analytics, then monitor indexing and relevant search traffic after launch. Submit the current sitemap. For applicable domain moves, review Google’s Change of Address process. Search visibility may fluctuate while a move is processed.
Google’s site-move guidance explains URL mapping and monitoring. Its redirect documentation describes permanent redirects. These are transition tasks; neither requires changing a useful URL simply because the visual design changed.
How do you redesign a dental website without losing Google traffic?
Start with the pages patients already find. Keep useful service, doctor and location URLs where practical, preserve accurate content, and map necessary moves to relevant replacements. Test appointment requests, call links and booking destinations before and after launch. No agency can promise unchanged Google traffic.
Give every practice page a decision.
A service page, a doctor profile and a location page answer different questions. Record each existing URL in the migration worksheet. If a doctor has left or a service is no longer offered, ask the practice to confirm the change before deciding whether the page should be updated, redirected or retired. Do not send every old page to the homepage.
Check the route to the practice.
Verify the address, hours, phone number and booking destination for each office. Test an appointment request through to receipt by the correct team, using a clearly labeled test without patient information. Keep private and confirmation pages excluded from indexing where intended.
Measure search and patients separately.
Compare Search Console clicks over equivalent periods and review important service and location pages individually. Record inquiries separately from completed new-patient visits. Our Northside Dental case study explains its client-reported patient change; it is not an SEO migration performance test.
Bring your current website to discuss a dental redesign. Start with what must keep working, then agree what should improve.
Put every URL in the plan.
Use this website migration worksheet to connect each existing page to a clear launch decision. It includes space for search traffic, the proposed destination, an owner and the live verification result.
Download the free migration worksheet (CSV)
Open it in Excel, Numbers or Google Sheets. The three example rows use example.com and contain no traffic data. Delete them, then add one row for each URL on your own site. No email required.
Before launch
Record the page’s purpose and Search Console clicks for a named date range. Mark whether the URL stays, moves to a relevant replacement, or retires without a replacement. Assign an owner to every decision.
At launch
Test the live URLs. Record the response status and final destination. Confirm that redirects reach the intended page, then check its canonical, indexing rules and internal links. Record the result and verification date.
After launch
Compare search performance over equivalent periods and log unresolved problems. Keep a separate record of inquiries or bookings so a traffic change is not mistaken for a business result. The worksheet helps organize the work; it does not guarantee unchanged rankings.
A redesign changes presentation, content, or customer journeys. A rebuild replaces more of the implementation or platform. Agencies use these words differently, so compare the proposed changes. Neither choice automatically requires a new domain or new page addresses.
When is a redesign enough?
Consider a redesign when the current site can support the changes your customers need. A weak opening message, unclear navigation, dated presentation, or a difficult mobile layout does not necessarily require replacing every part of the website.
Ask the team to demonstrate the proposed improvement in the current system. Can it support the required page structure? Can your staff maintain the content? Can the main customer journey work without fragile workarounds? Those answers are more useful than the age of the design alone.
We recommend protecting the parts that already serve customers well. Content that answers an important question, a useful service-page address, and a reliable booking integration may all deserve to stay.
When does rebuilding make sense?
A rebuild deserves consideration when a specific limitation prevents the agreed work. The site may depend on a difficult-to-maintain implementation, lack a workable content model, or require functionality that the current setup cannot support appropriately.
Ask for evidence of that limitation. Which workflow fails? What would repairing it involve? Why is replacing the foundation a better use of the project budget? A new technology name is not enough to answer those questions.
Also ask what will be retained. Rebuilding code does not make the business’s content, customer journeys, or search history disposable. A migration should carry forward useful assets and behavior while replacing the parts that need to change.
How should you compare cost and ownership?
Compare like-for-like scopes. A homepage visual refresh and a platform migration are different projects. Have each proposal identify page types, content work, integrations, testing, handoff, and the work required to transition from the current site.
Price the ongoing responsibilities too. Who maintains the system, publishes changes, fixes broken integrations, and controls the relevant accounts? Ask for an editor demonstration if your team will manage content after launch.
Confirm access to the domain, hosting, CMS, source files, analytics, and third-party services. Identify any license or export restrictions. Our custom website vs. template guide explains why design, ownership, and portability are separate decisions.
WTM custom-quotes each engagement. The existing site, intended changes, and transition work help define the scope. Bring the current site and the parts your business depends on.
What does this look like in practice?
WTM Studio moved from worldtechmiami.com to wtmstudio.agency. The legacy domain redirects to the current site. That is a domain migration as well as a brand transition, and it illustrates why addresses and existing paths need explicit attention.
A different project may keep the same domain and useful URLs while changing the experience. Our Back to 30 and Northside Dental case studies show website work for established businesses. Start the conversation with the business and its current journey.
Explore WTM’s website redesign service. We are based in Miramar, Florida and work nationwide. Tell us what needs to improve and what must keep working. The plan should address both.