WEBSITE MIGRATION AND LAUNCH WORKSHEET Branding Tatva | Prepared 26 October 2026 Service scope: https://brandingtatva.com/website-redesign Use this working copy to agree what stays, what changes and which evidence will support the launch decision. Copy the fields into your own project record. Opening this resource requires no account or email address. This is a planning aid. The agreed proposal defines delivery and testing. Search traffic, rankings and AI citations remain outcomes to measure. Keep passwords, access tokens, customer records and private analytics exports outside this worksheet. Share access through an agreed secure route. 01. DEFINE THE CHANGE Business and public website: Decision owner: Priority customer and service: Main action: enquiry / booking / purchase / another agreed action Work proposed: focused repair / refresh / rebuild / still being assessed Domain, CMS and hosting changes proposed: Content and language changes: Reason each change is needed: Target release date, time zone and approval owner: Separate necessary changes from preferences. A new visual design alone leaves the question of a CMS or domain replacement open. 02. RECORD WHAT ALREADY WORKS List existing service pages, articles, images and useful downloads. Include URLs found through the CMS, sitemap and available search records. Identify pages with relevant clicks, enquiries, inbound links or a clear customer task. Record missing information as unknown. Baseline period and time zone: Search property and report type: Country, device and page filters: Relevant queries and landing pages: Clicks and impressions: Verified enquiries and their measurement source: Known test activity or measurement gaps: Evidence location and reviewer: 03. CHOOSE A URL OUTCOME KEEP: retain a useful page at its current address. REVISE: improve the page while retaining its address where practical. CONSOLIDATE: combine overlapping material only when the destination still answers the old page's customer task. Record the reason for the decision. MOVE: map an old address to its relevant replacement. REMOVE: record why the material is being retired and whether a relevant replacement exists. An absent page without a replacement should return an appropriate 404 or 410 response. [2] Avoid sending unrelated retired pages to the homepage. Keep useful images and downloads in the inventory as well as HTML pages. [1] 04. COMPLETE ONE MAPPING RECORD PER OLD URL Old absolute URL: Customer task and useful content: Decision: keep / revise / consolidate / move / remove Proposed final absolute URL, or reason for removal: Content owner and approval: Expected old URL response: Observed response and redirect hops: Observed final URL and response: Destination title and canonical URL: Internal links and sitemap entry checked: Tester, date and evidence: Status: pending / passed / failed / out of scope with reason For a permanent move, review a server redirect using HTTP 301 or 308. Test the full path to the relevant final page; avoid loops and unnecessary intermediate redirects. A redirect is a canonical signal, rather than a promise about the result shown for a particular search. [3] Illustrative mapping, using example.com: Old: https://example.com/services-old Decision: move New: https://example.com/services Expected: permanent redirect to the relevant service page, then HTTP 200. Confirm that the destination actually answers the old page's task. 05. CHECK SEARCH ACCESS ON THE FINAL SITE For each page intended for search, record its response, crawl permissions, indexing directives and canonical destination. Check that staging access controls stay on staging and that intended public pages are accessible. Review titles, internal links, structured data and the final sitemap. [1] Check owner: Pages checked and pages still outstanding: Source of evidence: HTML / HTTP response / search tool / browser Blocking issue, owner and retest date: An HTTP 200 response shows a successful request; indexing still depends on the search engine. Track index observations separately. [2] 06. TEST THE CUSTOMER'S NEXT ACTION Starting page and chosen action: Expected enquiry, booking or checkout destination: Service, package and language context retained: Required fields and useful error messages: Consent choices and privacy information: Confirmation shown to the visitor: Delivery or booking receipt checked by the responsible owner: Test approved by, environment used and cleanup required: A working link alone leaves message delivery unverified. Agree permission before sending a test enquiry, placing an order or booking an appointment. Use test data and a controlled environment where available. 07. CHECK READING AND INTERACTION Record the browsers, viewport sizes and assistive methods actually tested. Review keyboard access, visible focus, headings, image descriptions, readable zoomed text, form labels and errors. [4] Also record mobile overflow, motion controls and reduced motion behaviour. Page and browser configuration: Task attempted and observed result: Issue, severity, owner and retest evidence: Tests still outstanding: A preliminary check covers only part of accessibility. Agree any fuller assessment and specialist review separately. [4] 08. AGREE THE RELEASE AND RECOVERY PLAN Exact candidate version and staging evidence: Content approval owner: Launch approver and agreed go or hold decision: Backup and recovery procedure reviewed by: Trigger for pausing or reversing the release: Responsibility for preserving enquiries received during the change: Launch time and support contact: Public version and checks completed after release: A recovery plan needs an owner and a tested procedure appropriate to the platform. Record the decision before changing the live site. 09. PLAN THE FOLLOW UP Compare equivalent periods, report types and filters after launch. Keep page responses, crawl activity, indexing, search clicks and enquiries as separate observations. Annotate the release and other material changes. Google advises monitoring both old and new URLs during a move. [1] First review date and owner: Later review date and owner: Priority pages or redirect issues to inspect: Sitemap action, receipt and date if required: Search or AI observation, exact query, date and source: Unresolved questions and next action: 10. RECORD THE HANDOVER Domain, hosting, CMS and analytics account owners: Redirect maintenance owner and review date: Content editing instructions delivered: Agreed support period and responsibilities: Known limitations and outstanding work: Evidence archive location: Final approval and date: For a website proposal, share your public URL, desired changes and the unresolved decisions. Keep confidential records in your own workspace. Website work receives its own scope and quotation. https://brandingtatva.com/contact?service=website-redesign#write SOURCES CHECKED 26 OCTOBER 2026 [1] Google Search Central: site moves with URL changes. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes [2] Google Crawling Infrastructure: HTTP status codes. https://developers.google.com/crawling/docs/troubleshooting/http-status-codes [3] Google Search Central: redirects and Google Search. https://developers.google.com/search/docs/crawling-indexing/301-redirects [4] W3C Web Accessibility Initiative: preliminary accessibility checks. https://www.w3.org/WAI/test-evaluate/preliminary/ The worksheet fields and decision records are Branding Tatva's planning format. The sources explain the technical checks; their inclusion implies neither an endorsement of the studio nor an outcome for your website.