Website redesign SEO checklist for service businesses

You want a better website, but you also want the links you have already shared to keep working. You want people to find your services, send an inquiry and book without wondering whether the new site received anything.

This website redesign SEO checklist is for the business owner approving the work. You can use it with a designer or developer before launch, even if you never open a code editor.

1. Agree what is changing

Write down whether the project changes your design, wording, page addresses, website platform, domain or booking tool. These are separate decisions, with different checks.

For example, a new homepage on the same platform may keep every existing address. Moving from one platform to another may change page paths and form handling. Replacing a calendar adds booking, availability and reminder checks.

Google has separate guidance for hosting changes that keep URLs the same. Ask your developer which type of move you are making. If you are unsure how much work you need, start with repair, refresh or rebuild.

2. Save a before-launch record

Make a simple spreadsheet with the pages people actually use. Include service pages, useful articles, booking links, downloads and the pages linked from your social profiles or email signature.

For each one, record its current address, purpose, proposed replacement and the person responsible for checking it. Add a note if it receives inquiries or has links from other websites. Google recommends mapping important old URLs to their new destinations.

Save your current Search Console and analytics reports too, if you have access. Record the date range and filters so you can make a useful comparison later. Keep a separate note of inquiries received, because a traffic number does not tell you whether someone could contact you.

3. Give old links a relevant destination

A redirect takes someone from an old address to another page. For an address that changes permanently, Google recognises server-side 301 and 308 redirects as permanent redirects. Your developer should choose and configure the appropriate method.

Here is an illustrative URL plan. These paths are examples, not instructions to change your own site.

Google warns against redirecting many old pages to an irrelevant destination. Update your own menu, article and button links to the intended current addresses too. Test some old links directly, rather than only navigating from the new homepage.

4. Check email and account access separately

Before anyone changes domain settings, confirm where your website, domain registration and email are managed. MX records direct incoming email to a mail server. A website launch should not casually replace the records your email provider needs.

Keep an account list with the provider, account owner, renewal contact and access needed for the project. Include your booking tool and payment provider when they are part of the agreed work. Share access through the provider’s user permissions where available. Keep passwords out of the public project checklist.

Ask who will confirm email still arrives after any relevant domain changes. Treat mailbox migration, contact migration and website rebuilding as separate scope items unless your agreement explicitly includes them.

5. Test the preview and the inquiry steps

Keep private previews suitably protected. For crawlable test pages, noindex can prevent search indexing, but Google must be allowed to crawl the page to read that instruction. Noindex does not stop a person with the link from viewing a page.

At launch, check that the public pages you want found are no longer carrying staging-only indexing restrictions. Keep private or utility pages excluded where appropriate. Ask the developer to check the actual published page, not just a setting in the editor.

Then try the site on your phone. Read a service page, follow its main button and complete the agreed test path. W3C recommends clear feedback for successful submissions and errors. An error should tell you what to correct.

• Check a missing required field and an incorrectly typed email address.
• Use agreed test details for a valid inquiry, with the owner’s permission.
• Confirm the inquiry is saved and the intended owner can find it.
• Check the notification separately. A success message alone does not prove an email reached an inbox.
• If booking is included, check time zones, confirmation and the agreed rescheduling or cancellation path.

Our guide to what happens after a website inquiry explains the handoff beyond the form. Avoid real customer data or charged purchases for a basic launch check.

6. Agree a launch and handover checklist

Put these items in the project’s shared checklist. Give each one an owner, a result and any unresolved issue. This is a practical starting point, not a promise that every project includes every item.

1. Pages and links: the agreed pages open, the menu works and important old addresses have been checked.
2. Mobile use: text, buttons, tables and forms remain usable on a narrow screen.
3. Contact and booking: the agreed test results are recorded, including who receives inquiries.
4. Search settings: public titles, descriptions, canonical addresses and indexing instructions have been checked.
5. Accounts and costs: you know who owns the accounts and which software charges continue.
6. Recovery and support: someone is responsible for backups, an available recovery method and any agreed support period.

Ask what can actually be restored if a problem appears. A copy of the design may not include form records, bookings or third-party account settings. Have the person responsible explain the limits before launch.

7. Check the live site after launch

Open the live addresses, repeat the agreed non-charged checks and look for missing images or downloads. Keep the results with the launch checklist so you know what was tested and when.

Review Search Console for important pages and unexpected indexing issues. Google notes that search rankings can fluctuate during a site move. Compare equivalent reporting periods and investigate changes page by page. Do not judge the whole redesign from one day’s traffic.

Make sure the sitemap lists the intended public addresses. Submitting a sitemap is a hint, not a guarantee that Google will crawl or index its URLs. It does not replace checking the pages and redirects themselves.

Before you approve launch, ask one clear question: “Can you show me the checklist, the results and anything still outstanding?” That gives you something concrete to review.