Siobhan.GEditor
A small business website redesign is not only a design handover. It is a transfer of decisions about which pages answer customer questions, which existing addresses remain valid, how enquiries are measured and who is accountable when a release changes the site's behaviour. A beautiful replacement website can arrive with missing service pages, broken internal links, accidental noindex instructions or forms that nobody has tested. The agency and client need one practical document that connects the old website to the proposed one, names decision-makers and defines how launch success will be checked. The purpose is not to promise unchanged rankings. It is to preserve useful information and minimise avoidable uncertainty during a substantial change.
.jpg)
Establish a useful baseline before anybody changes URLs
Begin with the current site, not a designer's proposed navigation. Export a URL inventory covering primary service pages, product pages, locations, articles, resources and significant files. Record which pages presently receive search clicks and impressions, which connect to valuable customer actions and which have known external links. Add their existing page titles, primary headings, canonical signals, indexability and internal link destinations where practical. This baseline is not a ranking guarantee: it is evidence that lets colleagues spot something important missing from the replacement build.
For a small accountancy practice, for example, a seemingly minor page explaining a specific bookkeeping service might generate qualified enquiries even though it is absent from the main navigation. A redesign that keeps only broad landing pages could discard that usefulness. Conversely, an obsolete campaign page might have little reason to survive. Record the decision for each category, including an explicit 'requires review' state. Google Search Console's performance reporting can help identify search queries and pages, but Search Console clicks are not equivalent to sales or all website traffic. Where conversion tracking exists, verify its definitions rather than adding incomparable numbers together.
Map old addresses to genuine destinations
Build a URL disposition sheet with the old address, intended new address or retirement decision, type of change, content owner, developer and test result. Keep stable URLs where possible when their purpose remains the same. Where a URL genuinely changes, select the closest helpful destination; do not send every retired blog post to the homepage. Google's official site-move documentation recommends server-side permanent redirects, such as 301 or 308, for permanent URL moves and warns that irrelevant mass redirects can be treated as soft 404s.
Check how trailing slashes, capitalisation, old campaign parameters and legacy file paths will behave. One old service page might legitimately be consolidated into a more comprehensive replacement; several unrelated pages should not all be mapped to a generic service overview merely to reduce the redirect list. The sheet should identify exceptional cases and keep the old-to-new relationship intelligible to an independent reviewer. After implementation, test representative and high-value old URLs to confirm that they reach the intended live page without loops or unnecessary chains. The existence of redirect rules in a ticket is not the same as seeing them work on the deployed website.
Preserve the meaning of content, not just its page count
Design teams sometimes reduce copy because a new layout has less space. That can improve readability, but it can also remove information users relied on: service boundaries, eligibility, practical steps, costs that were previously explained or answers to common questions. Compare old and new content at the level of customer need. Ask which questions each important page answered, which information must remain accessible and which material is genuinely obsolete. Give the final decision to a named content owner who can confirm business facts, not to a layout constraint alone.
Also check whether the new information architecture creates two pages promising to solve the same problem. A local agency may have one page for a service and several area pages; their purposes should remain clear without producing interchangeable text. If pages are consolidated, decide how internal links and navigation will point to the new destination. Write a brief for any substantive rewrite, marking preserved facts, revised claims and content requiring fresh approval. An approved mock-up is not sufficient evidence that every factual service statement is accurate on the live website.
Assign SEO metadata and technical responsibilities by template
The handover should specify which team owns titles, headings, canonicals, robots instructions, structured data where appropriate, image alternative text and XML sitemap output. Not every page requires identical treatment. A product detail template, service landing page and articles archive have different content and indexing considerations. Use representative examples from each material template rather than inspecting only the homepage. The agency should explain intended page purpose; developers should confirm where metadata originates and how the CMS can override it responsibly.
Staging sites frequently contain restrictions intended to prevent premature indexing. Before launch, establish precisely how those controls will change and who will verify the production outcome. A robots.txt restriction is not interchangeable with a noindex directive, and a canonical hint is not a substitute for a redirect. Google maintains separate documentation for robots meta directives and site moves; use those definitions instead of relying on a generic audit warning. Test whether key content is available in the rendered HTML and whether navigation actually links to it. Accessibility and page experience checks belong in the same implementation review because search visibility should not be pursued by making the site harder for people to use.
Protect enquiry tracking and operational handovers
A redesign may alter form fields, telephone links, booking widgets, consent flows, checkout steps or analytics tags. Establish which customer actions matter and what event or transaction indicates genuine completion. Test that forms deliver to the authorised mailbox or CRM, that required privacy notices remain suitable and that test submissions can be recognised without contaminating reports. Never assume a successful front-end thank-you page proves that the sales team received the enquiry.
Ask the business to identify who will maintain the new website and where credentials, documentation, design files and redirects will live after the agency finishes. A client should not be forced to reconstruct its own systems from a supplier's private inbox. Use role-based access, a named support contact and a controlled record of unresolved issues. When several suppliers are involved, designate one release coordinator rather than treating every missing decision as somebody else's responsibility. A small project benefits from a clear handover more than from an elaborate approval hierarchy.
Agree launch-day checks and a meaningful stop decision
Prepare a release checklist that can be tested against the actual production site. Confirm the intended domain, HTTPS behaviour, important page availability, old URL redirects, internal links, canonical and noindex settings, sitemap generation, forms, tracking and major mobile experiences. Include a rollback or correction approach proportionate to the platform and risk. The person authorising launch should understand which checks passed, which have acceptable documented exceptions and what would require the team to pause.
For instance, one broken low-priority archive link may be fixable shortly after release, while an inaccessible main booking form or accidental noindex on all service pages merits immediate attention. Treat these as examples for risk assessment, not universal numerical thresholds. Keep the release time, deployed version and responsible staff in the record. If developers and SEO colleagues are checking different environments, explicitly reconcile them before calling the site live. A signed-off staging crawl is useful, but a production read is essential because settings and hosting behaviour can differ.
Review performance and close the handover after release
Immediately after launch, retest critical old URLs, inspect a sample of important production pages, submit an accurate sitemap where appropriate and check Search Console for emerging crawl or indexing evidence. Continue reviewing over a sensible period rather than expecting search results to stabilise the next morning. Google notes that site moves can temporarily change search visibility while its systems discover and process the new addresses. Investigate changes by affected page and query group alongside real user journeys, not only by comparing total clicks on two arbitrary dates.
Close the project by delivering the URL map, resolved issues, unresolved risk list, ownership matrix, analytics changes, access instructions and a dated post-launch observation plan. A proper close-out means the client knows what happened and what remains to be checked. It does not declare that every SEO result is permanently protected. The strongest small-business handover enables a future team to understand why a URL moved, what the new page is supposed to do and how to identify an actual defect without repeating the original redesign research.
Source A: Google Search Central, site moves with URL changes for mapping, redirects and post-move checks. Source B: Google Search Console performance report guidance for interpreting search queries, pages and metrics. These official documents inform the handover; they do not guarantee specific ranking outcomes.