Keep the right links.
Check every change.

A website redesign needs a record of what exists, where each important URL will go, and how the new site will be checked after launch. Without that record, a familiar service page can disappear behind a cleaner menu while old search results, directory links, and bookmarks still point to its previous address.

This checklist focuses on that transition. It does not assume every redesign needs a domain change, a new page structure, or a rewrite of every service. Keep useful addresses and content where they still fit the business.

For a Southwest Florida company, the practical goal is continuity: people should still be able to reach the relevant service, location information, or inquiry route while the website improves.

Inventory the URLs before changing the navigation

Create one working spreadsheet from the current sitemap, a crawl of the public website, available analytics, Search Console reports, and any important campaign or directory destinations. Include useful PDFs and other downloads as well as ordinary pages.

These sources answer different questions. A sitemap shows intended pages; a crawl finds linked pages; reporting can identify addresses people still use. None should be treated as a complete inventory on its own.

Record each URL’s current status, page purpose, proposed action, intended final address, and person responsible for checking it. Mark important inquiry pages and documents so they receive individual testing.

Save the current titles, main headings, and substantive content for pages you plan to replace. This gives the team a reference when deciding whether the new version still answers the same customer question. It is especially useful when a page is being merged into a broader service page.

Give every changed address a deliberate destination

Use the inventory to make decisions before development is considered finished. “Keep,” “move,” “merge,” and “retire” are more useful instructions than “update later.”

The following paths are hypothetical examples, not claims about a particular business’s existing website:

A mapping is a business decision as well as a technical one. Someone familiar with the services should confirm that the destination satisfies the old page’s intent.

Google’s site-move guidance recommends preparing a URL map and warns against redirecting unrelated old pages to the homepage. A homepage that does not answer the original request is a poor substitute for a relevant destination.

Implement redirects and test the actual response

For a permanent URL change, use a permanent server-side redirect where the platform supports it. Google identifies 301 and 308 as permanent redirects. Ask the developer to record the actual response and final destination for each changed address.

Test the address a customer would use, including relevant older path formats. Do not rely solely on clicking the new menu, because it may never visit the old URL. Check that the redirect reaches the intended page directly, that the destination loads, and that it does not start another avoidable redirect chain.

Review meaningful query parameters and existing deep links individually. A rule that drops every parameter or sends every unmatched path to one page can conceal errors.

Update links within the new site to the final addresses. The header, footer, article links, buttons, and downloadable documents should not depend on the migration redirects for routine navigation. Keep the mapping as an operating document so later edits do not accidentally remove a necessary rule.

Align canonical addresses and indexing settings

Choose the preferred public version of each page and use it consistently. A page’s canonical reference, internal links, and sitemap should agree. Google describes redirects and canonical annotations as signals; they help indicate the preferred URL, but Google can select another canonical. See its canonical URL guidance.

Check the new site for references to a preview domain, an old host, or a temporary development address. A copied template can look correct while its metadata still points elsewhere.

Make indexing checks specific. Remove staging restrictions from the public pages that should be indexed, while keeping genuinely private or intentionally excluded pages protected. Review both page metadata and response headers: Google supports noindex in either location. A robots.txt block can prevent Google from seeing a page’s noindex instruction; the two controls are not interchangeable.

Have the developer record the launch settings rather than asking the owner to infer them from what appears in the browser.

Use a launch checklist with a named sign-off

Before publishing, assign a person to verify each category. A useful release checklist includes:

• Important old URLs reach their intended destinations.
• New public pages return the expected successful response.
• Titles, headings, service information, and contact details are accurate.
• Canonicals and internal links use the final public addresses.
• Forms, phone links, booking routes, and downloads work on mobile.
• Public indexing settings match the agreed page inventory.
• The sitemap lists the intended canonical pages.
• Analytics and Search Console access remain available to the business.

After launch, submit or update the sitemap through Search Console where appropriate. Google states that sitemap submission is a hint, not a guarantee of crawling or indexing.

A normal same-domain redesign does not require Search Console’s Change of Address tool. Google’s move instructions reserve that step for applicable domain moves, not ordinary path changes or a switch between HTTP and HTTPS.

Monitor page behavior as well as search traffic

Save a dated launch record and a reporting baseline. During the first day, prioritize availability, redirects, forms, and obvious errors. In the following weeks, review the old and new URL groups, indexing information, search impressions and clicks, and actual inquiry handling. These are suggested operating checkpoints, not a promised recovery schedule.

Search Console’s URL Inspection tool distinguishes information about Google’s indexed version from a live test. Use the live test to investigate the current page; use indexed information to see what Google has recorded. A successful live test does not prove that the page is indexed or will appear for a particular query.

Investigate a drop with a specific page and timeframe. Was its address changed? Is it reachable? Did its useful content disappear? Is a form failing? Have search impressions changed, or only measured visits? Avoid treating every movement as a ranking problem before checking implementation and reporting.

Connect this review to local visibility work so service and location pages receive attention alongside the homepage.

Review the migration before approving launch

Bring your current sitemap and proposed page list to a website design conversation. Local Legacy Consulting helps businesses in Port Charlotte, Fort Myers, and Cape Coral plan a website refresh with specific destinations, checks, and follow-up responsibilities.