Website Redesign SEO Checklist for an Established Small Business

To reduce avoidable SEO disruption during a website redesign, inventory current pages, preserve useful content, map necessary URL changes, and check the actual public site before treating launch as complete. Use this checklist whether you choose DIY, a freelancer, an agency, or a managed rebuild.

1. Inventory URLs, useful content, and search performance

Create a worksheet with one row per current URL: page purpose, useful content to retain or update, and a keep/change/remove decision. Record the proposed destination for anything changing. Include service pages, location pages where relevant, and older pages worth reviewing—not just items visible in the main navigation.

Review copy for accurate services, service areas, and contact details. Preserve helpful explanations rather than deleting them simply because the layout is changing. Ask the owner to confirm business facts before rewriting.

Save a prelaunch search baseline. Search Console’s Performance report provides clicks and impressions, page and query groupings, and adjustable date ranges. Use Google’s Performance report guide to choose comparable views for later review.

2. Map necessary URL changes to equivalent replacements

Keep existing URLs when they still make sense; a visual refresh is not, by itself, a reason to rename every page.

For permanently changed addresses, Google recommends server-side redirects such as 301 or 308. See Google’s redirect guidance. Choose destinations by purpose: someone seeking AC repair should reach the replacement AC repair page, not a general introduction.

Illustrative example only: This fictional HVAC business is changing one service address. These paths are examples, not a recommended ranking strategy.

Google warns that unrelated redirects may be treated as soft 404s; removed pages without suitable replacements should return 404 or 410. Follow Google’s site-move guidance rather than sending every retired URL to the homepage. Have the business owner approve the destination choices before implementation.

3. Keep staging separate from the public website

Use a separate staging environment to review the rebuild before publishing it to production—the public website customers use. Treat preview approval as approval of the proposed work, not confirmation that the public site is ready.

Confidential preview: Keep it password-protected. Google recommends password protection for private content; noindex does not prevent visits by people who know a public page’s address. See Google’s content-access guidance.

Public, nonconfidential preview: Use noindex to exclude it from Google’s index. A noindex directive tells Google not to index a page, but Google must crawl the page to read it. If robots.txt blocks crawling, Google cannot read that page’s noindex directive. Google’s noindex documentation explains this requirement.

Robots.txt controls crawling; it does not reliably keep URLs out of search. Google may discover and show a blocked URL through links elsewhere. This distinction is covered in Google’s robots.txt guide. Choose access protection based on confidentiality, not convenience.

4. Check production—not just the approved preview

Have the person handling deployment record pass or fail for each item on the actual production website. Ask for tested URLs and notes on corrections, using Google’s migration guidance as a reference.

• Public access: Confirm intended public search landing pages load without the staging password.
• Indexing permissions: Confirm Google can crawl those pages and that no unintended noindex remains in page settings or HTTP response headers. Check production separately from staging.
• Canonical addresses: A canonical declares a preferred page address; it is a signal, not a command forcing Google’s choice. Verify intended production addresses, not preview or unrelated URLs. See Google’s sitemap guidance for preferred-URL planning.
• Redirects: Test old paths against the approved map and confirm each redirect goes directly to its final, relevant destination.
• Internal links: Update navigation and in-page links to production destinations instead of relying on redirects.

Keep confidential staging password-protected. Approving the design does not replace these production checks; confirm implementation details for the chosen platform before launch. Ask who will correct any failed item and when it will be rechecked.

5. Submit the production sitemap in Search Console

Build the sitemap from intended production canonical URLs, leaving out staging addresses and superseded paths. Submit it through Search Console after checking production.

The Sitemaps report can surface access and processing errors. Sitemap submission is a hint to Google, not a guarantee of crawling or indexing. See Google’s sitemap submission guide.

Treat submission as a separate discovery step, not a repair for wrong redirects or unintended noindex restrictions. Do not accept “sitemap submitted” as the sole evidence that launch checks passed.

6. Assign monitoring and follow up after launch

Before launch, name someone responsible for monitoring and someone able to make corrections. Agree on a follow-up schedule and keep a shared issue log with affected URLs, actions, and recheck dates.

Compare clicks and impressions with the prelaunch baseline using comparable date ranges and page or query groupings. Account for changed paths: review the old and replacement pages together rather than interpreting an old URL’s decline in isolation.

Use the Page indexing report to investigate intended production pages that remain unindexed, including unexpected noindex exclusions. For individual pages, use URL Inspection to examine access problems and, in the indexed result, Google-selected canonical URLs.

Search visibility can fluctuate during a site move. Google’s migration guidance discusses this risk. Neither careful implementation nor sitemap submission guarantees indexing or unchanged rankings. Focus follow-up on finding correctable problems, not promising a recovery date.

If you’re planning a rebuild of an existing U.S. business website, explore Flaria’s managed website rebuild. Make URL mapping, production checks, and post-launch responsibilities part of the scope discussion.