Website redesign SEO checklist.
Protect your search visibility.

Before launch: record what already works.

Export the URLs that earn impressions and clicks in Search Console. Save the reporting dates, page titles, descriptions, canonicals, useful content and internal links. Record inquiries separately so you can compare search visibility and business results after launch.

Give each old URL a decision: keep it, move it to a relevant replacement, or retire it when there is no useful replacement. Preserve working addresses where practical. Do not redirect unrelated pages to the homepage.

Include the journeys customers rely on: forms, booking, calls and integrations. Name the person responsible for each one. Keep staging restrictions documented so they do not accidentally carry over to the public site.

Use the free migration worksheet to keep the old URL, planned destination, owner and test result together.

Review staging before cutover.

Use a written comparison of the old and proposed pages. Check valuable copy, headings, internal links and page addresses alongside the new design. Test mobile navigation, forms and booking paths with approved test data. Keep a record of access restrictions and indexing controls that must change at launch. Google includes testing and URL mapping in its site-move preparation guidance.

At launch: test the live URLs and customer journeys.

Check the published site, not just the preview. Pages intended for search should return HTTP 200, allow indexing and identify the intended canonical URL. A moved page should use a permanent redirect to its relevant replacement. Test the old address and inspect where it actually lands.

Update internal links and the sitemap to point to the final addresses. Check robots.txt, meta robots and X-Robots-Tag headers. Keep intentional exclusions, such as private or confirmation pages, excluded.

Test forms and booking through to receipt by the right team. Check analytics and confirmation states. A successful animation does not prove that the business received the inquiry.

Google’s site-move guidance explains URL mapping and monitoring. Its redirect documentation explains permanent redirects. For a domain move, review whether Google’s Change of Address process applies.

A design change is not a Change of Address.

If the domain and URLs stay the same, do not submit a Change of Address simply because the design changed. Google’s Change of Address tool is for moving a site to another domain or subdomain. Its documentation also excludes HTTP-to-HTTPS changes and www-to-non-www changes. Keep those separate from the design work.

Write redirect rules around a real destination.

Make the decision in the URL map before implementing a rule. A page that stays at the same address does not need a redirect. A page that moves needs its own relevant destination. If several pages become one useful resource, review whether that resource actually answers the original questions. A broad rule that sends every missing URL to a generic page hides the decision instead of resolving it.

Use permanent server-side redirects for permanent moves. Check the entire response chain, including HTTP, HTTPS, www and non-www versions. A successful final page does not mean the starting address reached it directly. Google’s redirect documentation explains the signals different redirect types send.

Test specific routes before broader patterns. Include paths with trailing slashes, old campaign links and URLs that carry useful inquiry context. Confirm that a rule does not intercept forms, booking callbacks or private application routes. Keep a rollback copy of the previous configuration, and assign a person who can restore it.

Pantheon’s SEO migration checklist also recommends testing the complete redirect map and updating internal links to final URLs. Use that as a second review of the implementation, alongside your own recorded destinations.

A real migration: WorldTech Miami to WTM Studio.

Our studio moved from worldtechmiami.com to wtmstudio.agency. We can show the actual addresses and how they respond, not just a migration checklist.

Same page. New domain.

On October 12, 2026, we checked six old-domain URLs: the homepage, web design, pricing, dental, med spa and contact pages. Every one returned a single 301 redirect to the matching path on wtmstudio.agency. The dental page led to the dental page; the contact page led to contact. None of these six was sent to an unrelated homepage.

Check the destination, too.

All six destinations returned HTTP 200 with a self-referencing canonical and no noindex in the page meta tag or HTTP header. All six appeared in the current sitemap. The published robots.txt rules allowed Googlebot, Bingbot and OAI-SearchBot to crawl those paths.

Download all six dated checks (CSV). The file records the exact URLs, redirect status, number of hops, final response, canonical, indexing directives, robots permissions and sitemap inclusion. See three examples below.

What this proves, and what it does not.

These are current technical observations, not a record of prelaunch testing. They demonstrate the six working mappings and the checked crawl settings on that date. They do not prove that Google indexed every page, rankings stayed unchanged or AI search recommended the business. A complete migration review also needs the old URL inventory, content checks, analytics, inquiry tests and follow-up search data.

Apply it to your dental group.

Keep a separate row for each practice, service and provider URL that needs to move. Record the intended destination before launch and the observed destination afterward. Technical results belong beside the search baseline, not in place of it. See how we plan DSO and multi-location website projects.

Planning your own move? Send your current website. Start with what must keep working, then agree the design, migration scope and quote before the build.

Worked example: keep the dental page’s purpose.

One row in our dated check starts at https://worldtechmiami.com/dental/ and ends at https://wtmstudio.agency/dental/. The path stays the same because the page still represents dental website design. The domain changes; the page’s job does not. This is a concrete mapping, not a rule that sends all old dental content to the new homepage.

Read that row in order: the old HTTPS address returns 301, the destination returns 200, and the destination’s canonical identifies that same new URL. Then read the separate indexing and sitemap checks. A redirect response alone would not reveal an accidental noindex on the destination. Likewise, a valid canonical would not show whether the old address still worked.

The contact-page row follows the same pattern, with /contact/ preserved. That is useful technical evidence, but it does not test a form submission or prove that an inquiry arrived. Treat delivery as its own check with an approved test, a timestamp and confirmation from the receiving system.

These six observations concern the exact HTTPS addresses in the October 12 file. They do not certify every old URL, every hostname variant or every HTTP request. For your own migration, expand the inventory with Search Console exports, existing links and known campaign addresses. Test those addresses rather than assuming a successful homepage test covers them.

After launch: compare pages, not just totals.

Submit the current sitemap and inspect important URLs in Search Console. Compare equivalent reporting periods, then review valuable service and location pages individually. A rise in impressions for new queries can change the sitewide average position without showing what happened to an established page.

Investigate missing pages, wrong destinations, indexing restrictions and broken inquiry paths. Keep a dated issue log. Measure qualified inquiries and bookings separately from search clicks. A technical check cannot establish the cause of a traffic or sales change.

The first 90 days: a review plan.

This is a suggested monitoring schedule, not Google’s processing timetable or a promise of ranking recovery. Use the same measures at each review, and investigate a broken customer path as soon as it is found.

Use Google’s guidance on investigating search traffic drops when interpreting changes. An observation after launch is a reason to investigate, not proof that the redesign caused it.

Keep the comparison useful after day 90.

Continue reviewing the pages that matter to the business. Set a recurring review that your team can maintain, with extra checks after major content, platform or booking changes. Keep the original baseline and the dated issue log. Do not replace them with a new baseline each time a result disappoints.

Separate three questions: can the page be reached, can search engines index it, and does it lead to a useful inquiry? Record redirects and response codes for the first question, indexing evidence for the second, and confirmed inquiries for the third. None is a substitute for the others.

When impressions change, compare the same page and query over equivalent periods. Note changes in the services offered, seasonality, page content or tracking. If a previously useful page loses traffic, inspect its current status, canonical, content and internal links before rewriting it again. A missing page needs a different response from a page that appears in search but attracts few clicks.

Keep a private copy of the old site and crawl records so you can inspect what changed. That is a practical recommendation in Search Engine Land’s redesign checklist. Use the records to compare a specific page, not to assume the previous version was correct in every detail.

For domain moves, Google recommends keeping redirects for at least a year in its site-move guidance. Do not remove working migration redirects just because the launch checklist is complete.

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.

Download the launch and monitoring checklist (CSV). Assign an owner, record the result and link the evidence for each task. The suggested review dates are planning checkpoints, not promises about search performance.

Does rebuilding change the SEO checklist?

The same preservation work applies. A redesign changes the experience; a rebuild may also replace the platform or implementation. Neither automatically requires a new domain or new URLs. Ask which constraint justifies a rebuild and which useful content, addresses and integrations will stay.

Compare the proposed work in our website redesign service and custom website and template guide.

For the search foundations behind the redesign, read what schema markup does, how Google and ChatGPT search differ and what llms.txt can and cannot do. These explain different parts of discovery; none replaces accurate pages and working customer journeys.

What should your redesign quote include?

Ask the proposal to name the page types, content work, integrations, URL mapping, launch checks and handoff. Confirm who owns the domain, hosting, CMS, source files and analytics, and who investigates problems after launch.

Every project receives a custom quote based on scope. Migration complexity, locations, content and integrations affect the work. Ongoing SEO is not automatically included. See pricing and real examples of project scope.

Compare what the proposals include.

Use our free website quote comparison tool to record migration, content, ownership, testing and support alongside known costs. A lower total is only useful when you understand what is included.