Website Cutover and Initial Optimization SOP

Tekton website cutover and initial optimization SOP

Process owner: Tekton website and SEO team
Use this for: Existing WordPress, Wix, Duda, Avada, and similar sites being rebuilt in Tekton’s GitHub and Cloudflare Pages system
Last revised: July 2026
Review trigger: Review this SOP whenever Cloudflare, GitHub, GoHighLevel, Search Console, or another named platform materially changes the interface or workflow described here.

Read this first

A website cutover is not a redesign project. The job is to move the existing website into Tekton’s system without losing pages, rankings, leads, email, reviews, maps, or anything else the business depends on.

That sounds simple, but most cutover problems come from things nobody saw during the first walkthrough. A page may be indexed even though it is not in the menu. A contact form may look fine but still depend on WordPress. A review widget may be pulling from the wrong Google Business Profile. A registrar may show DNS records even though another provider is actually authoritative. The new site can look perfect and still break the client’s email if one DNS record is missed.

This SOP is written in the order the work should happen. Follow it from top to bottom. Discovery work can happen while the site is being rebuilt, but do not skip a checkpoint just because the preview looks ready.

The basic flow is:

1. Understand the current site and everything connected to it.
2. Build a complete list of public URLs.
3. Capture the site on a safe working branch and inventory its full runtime dependency graph.
4. Localize every required asset and prove the clone works with the old origin unavailable.
5. Begin visual reproduction QA only after the localization gate passes.
6. Complete the first technical optimization pass.
7. QA the exact immutable deployment that may go live.
8. Copy the authoritative DNS zone into Cloudflare and prove nothing was lost.
9. Move DNS authority to Cloudflare while the old website still serves.
10. Put the approved code on the production branch and verify Cloudflare built the same commit.
11. Attach the live domain and activate approved redirects.
12. Turn on the approved search configuration.
13. Test the live website, forms, email, and monitoring plan.

The cutover is finished when the live site works, the lead path works, email still works, search settings are correct, and the evidence packet proves it.

Live-change approvals

Working on a branch, building previews, auditing pages, and preparing files are internal work. The following actions affect a live system and need separate approval:

• Pushing or merging the approved commit to the production branch
• Publishing the production Cloudflare Pages deployment
• Changing nameservers, DNS records, DNSSEC, or DS records
• Attaching the apex or www domain to Cloudflare Pages
• Activating hostname or route redirects
• Changing production canonicals, robots rules, or indexability
• Adding Search Console verification records or submitting a sitemap
• Requesting indexing, removals, or temporary removals in Search Console
• Submitting live forms that trigger client workflows or notifications

Where the mission or runbook defines an exact approval phrase, that phrase is mandatory. Approval must also name the domain or project, the exact action, the commit or artifact when relevant, the approver, the timestamp, the launch window, and the rollback owner. Approval for one action does not authorize another. “Looks good,” “go for it,” “yes,” and “ship it” do not count as approval for a live change.

Use approval records that make the consequence obvious. Examples:

• APPROVE EXECUTE: deploy [domain] commit [SHA] to Cloudflare Pages production.
• APPROVE LIVE CHANGE: activate Cloudflare nameservers for [domain] using the attached DNS parity and rollback record.
• APPROVE LIVE CHANGE: attach [hostnames] to Cloudflare Pages project [project] and activate the approved redirects.
• APPROVE LIVE CHANGE: activate the approved production indexing configuration for [domain] and submit [sitemap URL].
• APPROVE CLIENT UPDATE: run labeled live form tests on [domain] using the attached test plan.

Current team baseline: Nick must approve DNS, domain, canonical, indexing, and Search Console changes.

Before work starts

Create one cutover control record. This can live in the project folder, TaskTracker packet, or approved review system. It should contain the facts everyone will need later so nobody has to hunt through chat during launch.

Start by defining the boundary of the job. Record what is included, what is deferred, and what must remain unchanged. Name any protected pages, sections, photographs, claims, functionality, URLs, or integrations. State whether this cutover includes redirects, metadata, schema, forms, reviews, maps, Search Console, and DNS. Separate the cutover from Core 30 or ongoing SEO work. Confirm that the client and Tekton are authorized to reproduce the site’s code, content, and assets before copying them into the new system.

Record the client, live domain, current preferred hostname, proposed preferred hostname, GitHub organization and repository, repository privacy classification, repository default branch, working branch, approved production branch, Cloudflare production branch, Cloudflare account and Pages project, registrar, authoritative DNS provider, current host, current web-origin and SSL/TLS behavior, email provider, GoHighLevel location, Google Business Profile, Search Console properties, evidence-folder location, current cutover status, launch window, final approver, launch monitor, and rollback owner.

Also write down who owns each part of the work. One person may cover several roles, but the responsibilities still need names:

• The cutover operator keeps the steps, evidence, and approvals in order.
• The builder handles the site files, builds, commits, and preview deployments.
• The SEO reviewer handles URLs, redirects, metadata, headings, schema, canonicals, sitemap, and indexability.
• The DNS operator handles zone capture, parity, nameservers, and rollback.
• The GoHighLevel owner handles forms, workflows, recipients, and test results.
• The QA reviewer checks every route, device class, interaction, and live result.
• The final approver authorizes the exact live action and scope.
• The launch monitor runs and records the immediate and stabilization checks.
• The rollback owner stays available during the launch window and knows how to restore the previous website.

Do not start the live portion of the cutover if nobody owns rollback.

Maintain an access matrix with the system, account or property, access owner, tested user, access level, last verified time, and any missing permission. Reverify access to GitHub, Cloudflare, the registrar and authoritative DNS, GoHighLevel, Search Console, and the old host during the final go/no-go check. Intake access that worked weeks earlier is not proof it will work during launch.

Evidence standard

Evidence should prove what was checked, against which build, and who accepted any exception. Use the same status language throughout the project:

• PASS
• FAIL - BLOCKER
• FAIL - NON-BLOCKER
• BLOCKED
• N/A - APPROVED

Each evidence row should include a requirement ID, the requirement, owner, status, evidence link or file, commit and deployment tested, timestamp, and any exception with its approver. A screenshot without the route, device, build, and expected result is not enough evidence.

Keep the records organized so the launch operator can find them quickly. The evidence location should include intake and access, source URL inventory, DNS before, preview QA, SEO audits, redirect map, prelaunch approvals, DNS activation, domain cutover, live QA, form tests, and closeout and monitoring. Equivalent project folders or ledgers are acceptable as long as nothing is omitted.

Phase 1: Find out what is really live

Start with access and ownership

Before rebuilding anything, confirm access or a named owner for the current CMS, GitHub, Cloudflare, the registrar, the authoritative DNS provider, business email, GoHighLevel, the Google Business Profile, Search Console, analytics, and backlink data. Prefer delegated access over shared passwords wherever the platform supports it. Request registrar, DNS, CMS, Search Console, Google Business Profile, and prior-agency access at the start because those requests commonly delay launch.

Do not assume the registrar controls DNS. The domain may be registered at GoDaddy while the nameservers point to a previous agency, Cloudflare, or another provider. In that case, the DNS screen inside GoDaddy may be stale and completely unrelated to the live zone.

Check the active nameservers first. Those nameservers tell you which provider is authoritative. Once that is known, capture the records from that provider.

At this stage, you are only collecting information. Do not change nameservers or live DNS.

Capture DNS and email before touching the domain

The DNS record is not just about the website. It may also control email, phone systems, verification services, subdomains, scheduling tools, and other business software.

Capture the active A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, and any other records. Record each record’s name, value, priority, and purpose when known. Save a zone export if the provider supports it. If not, take complete screenshots and build a structured record list.

Pay special attention to email:

• MX records show where mail is delivered.
• SPF is normally stored in a TXT record. Do not accidentally create multiple SPF policies.
• DKIM selectors allow signed mail to validate.
• DMARC controls how failed mail authentication is handled.
• Autodiscover, verification, and provider-specific records may also be required.

Check whether DNSSEC or a DS record is active at the registrar. A stale DS record after nameserver migration can make the entire domain fail with SERVFAIL, even when the Cloudflare zone looks correct.

If another agency controls the active DNS, get the full authoritative zone before proceeding. A partial record list is not enough for a safe launch.

When a DNS, email, or service configuration is unfamiliar, do not guess:

1. Stop before changing it.
2. Research the registrar, DNS host, email provider, and record type.
3. Confirm what every unfamiliar record or delegation supports.
4. Ask the current provider or previous agency for documentation when necessary.
5. Record unresolved risks before launch planning.

Build the full URL inventory

The navigation is only the visible part of the site. It does not tell you every page Google or users can reach.

If the existing site is WordPress, review Pages, Posts, public custom post types, landing-page libraries, media attachment pages, taxonomy archives, author archives, date archives, search-result archives, and other generated archives. Also inspect archived or trashed pages that were previously public and any prior-agency route or redirect records. Then compare that list with the XML sitemap, sitemap index, a full crawl, Search Console, analytics landing pages, backlink data, existing redirects, and archived URLs.

The reason for doing this early is simple: you cannot honestly say “every page passed QA” until you know what every page is.

For each URL, record:

• The current URL and page type
• Whether it is indexed or receiving traffic
• Its current canonical URL
• Any useful clicks, queries, backlinks, or internal links
• The matching route on the new site
• What should happen to it at cutover
• Notes, decision evidence, and unresolved risks

Give each URL one disposition:

Retain it. Reproduce the page on the new site.

Keep it now and improve it later. This is common for pages that belong in Core 30 or later SEO work. A cutover is not the time to rewrite the whole site.

Merge it and redirect it. Use this when several pages compete for the same service or intent. For example, if a site has three old hardscaping pages and one current hardscaping page, compare the content and search value before consolidating them into the strongest destination.

Redirect it without a content merge. Use this only when there is already a clearly equivalent destination.

Retire it. If there is no useful replacement, return a real 404 or an approved 410. Do not redirect unrelated pages to the homepage.

Investigate it. Hold the decision when traffic, backlinks, ownership, or purpose are unclear.

An unlinked page is not automatically a bad page. Search Console may show that it still receives traffic. Backlinks may point to it. It may be a landing page from an old campaign. Check before removing it.

When pages appear to compete, compare the full cluster before deciding what survives:

• Search intent
• Content overlap
• Geographic target
• Search Console impressions, clicks, queries, and landing-page performance
• Backlinks and external references
• Internal links
• Conversion or lead value
• Metadata, headings, and canonical signals
• Which URL is the strongest long-term destination

Do not merge pages merely because their names are similar. A route with different local intent, valuable backlinks, or real conversions may deserve to remain separate.

Phase 1 checkpoint

Do not move on until the team knows who controls the domain, where authoritative DNS lives, how email is configured, and what should happen to every known public URL. Any missing DNS zone, unknown email service, or unexplained high-value URL is a blocker.

Phase 2: Set up the safe working environment

Confirm the repository and Cloudflare project

The normal provisioning path should reproduce the current site in a dedicated GitHub repository, create the matching Cloudflare Pages project, and connect Pages to that repository. GitHub is the source of truth for website code. Cloudflare Pages is the build, preview, and publishing layer. If automation created the wrong repository, account, project, or connection, correct that mismatch before editing the site.

Make sure the repository belongs to the correct client, has the approved public or private classification, and that the Cloudflare account and Pages project are the right ones. Confirm the build command, output directory, runtime version, package manager and version, lockfile policy, environment variables, and production branch.

Some repositories use main, but do not hard-code that assumption. Record the branch GitHub treats as production and the branch Cloudflare Pages is configured to deploy. They must agree.

Check branch protection and required status checks. Confirm secrets are stored outside the repository. If the site uses Git LFS, submodules, or framework-specific routing, document that before the first deployment.

Create the working branch

Sync the repository, record the starting commit, and create a dedicated branch for the cutover. Working-branch commits may be pushed so Cloudflare can create preview deployments. Direct work on the production branch is not allowed.

Every review build needs a deployment record containing:

1. Working branch
2. Commit SHA
3. Cloudflare deployment ID when available
4. Immutable Cloudflare Pages deployment URL for that exact build
5. Stable branch or project URL
6. Build result
7. Preview noindex or access-protection result

A branch alias or moving *.pages.dev URL is useful, but it is not proof of one exact build.

Use this instruction when handing the work to a builder or AI agent:

Create a dedicated branch for this cutover QA and optimization work. Make all changes on that branch. Do not push or merge to the production branch without approval. After each meaningful batch of changes, provide the commit SHA and latest immutable Cloudflare Pages deployment URL for visual QA.

Repeat the instruction whenever the working context changes or a new builder, AI agent, or operator takes over.

Protect every preview hostname

Branch previews, immutable deployment URLs, the stable Pages project hostname, and staging domains must stay out of search results.

Use a host-aware control such as Cloudflare Access, an X-Robots-Tag: noindex, nofollow header, or an HTML noindex rule that applies only to nonproduction hosts. Do not rely on canonical tags alone. Also do not rely only on robots.txt, because blocking the crawler can prevent it from seeing the noindex instruction.

Test preview protection before sharing the first deployment.

Phase 2 checkpoint

You should now have a clean working branch, a successful immutable deployment tied to a commit, and proof that preview hosts are protected from indexing. Nothing should have touched production.

Phase 3: Localize the clone before visual QA

The first job after capture and route inventory is to make the clone independent of the source site. Follow the Clone Asset Localization Gate before opening the source and preview for side-by-side visual review.

Inventory and localize images, CSS, JavaScript, fonts, font stylesheets, icons, SVGs, sprites, favicons, manifests, videos, posters, and recursively referenced dependencies. Inspect srcset, lazy-load attributes, CSS url(...) and @import, JavaScript-loaded assets, inline/background styles, and separate desktop/mobile source fragments.

Maintain the asset manifest and approved external dependency ledger. Run npm run verify:clone-independence, deploy a noindexed immutable preview, block the source origin, and prove the preview makes zero unapproved source-origin runtime requests. If fonts, icons, backgrounds, scripts, images, or interactions break while the source is blocked, the clone has not passed this phase.

Only after that gate passes should the team begin faithful visual reproduction. The new site should carry over the approved pages, content, layout, and functionality before broad improvements.

Open the current live page and the matching immutable preview side by side. Check the header, navigation, page content, typography, colors, backgrounds, spacing, images, buttons, forms, reviews, maps, interactive sections, and footer.

Treat the header and navigation as high priority. Verify that desktop navigation and mobile navigation open and close, dropdowns and flyouts display correctly, every item reaches the expected destination, hover and active states work, the logo and primary calls to action behave correctly, and the header remains usable across relevant widths.

Do this for every retained URL in the inventory, including pages that are not linked from the navigation. Faithful reproduction must be verified on desktop, mobile, and tablet before optimization begins. If a physical tablet is not available at this stage, use an approved emulator and repeat the tablet check on a real device when practical.

Choose an audit workflow

Either of these workflows is acceptable as long as every issue and retest is recorded.

Audit first, then fix. Review the full site into a notes document or QA ledger, record every issue, group related fixes, then send controlled batches to the builder. This is Jakob’s preferred method because it keeps the reviewer focused on inspection instead of switching repeatedly between auditing and implementation.

Fix and verify one issue at a time. Capture the evidence, request the correction, review the next immutable deployment, record the retest, and continue.

Work in small batches

Do not make five rounds of changes and wait until the end to discover that the first round broke mobile.

After each meaningful batch:

1. Build the branch.
2. Create a fresh immutable deployment.
3. Record the commit and deployment URL.
4. Check the pages changed in that batch.
5. Recheck shared components such as the header, footer, navigation, forms, and global styles.
6. Recheck representative routes that were not changed so shared-code regressions are caught.
7. Check desktop and mobile. Remember that the site may use separate templates, captured fragments, or breakpoint-specific code. A desktop fix is not proof that mobile remains correct.
8. Review relevant console and network failures.
9. Record pass or fail evidence before moving to the next batch.

When reporting a defect, include the page, device or viewport, expected result, actual result, severity, assigned owner, fix commit, exact immutable deployment, and retest result. For visual-parity issues, capture both the correct live reference and the incorrect preview, label which is which, and explain behavior, breakpoint, animation, spacing, or interaction details that screenshots alone do not show. Continue iterating on fresh immutable deployments until the result is correct.

Keep all required assets in the repository

The final site must not load required presentation or behavior assets from the old WordPress installation, previous agency CDN, builder host, or live source origin. Localize images, CSS, JavaScript, fonts, icons, SVGs, sprites, favicons, manifests, video/poster files, and recursive dependencies at the start of Phase 3, not as cleanup after visual QA.

Validate response types while downloading. Reject login pages, bot blocks, 404 pages, and HTML error shells saved under asset extensions. Verify every localized path exists in the built output and returns the correct MIME type on the immutable preview.

Do not bulk-delete old scripts or styles just because they look unnecessary. Captured WordPress, Avada, Duda, Wix, Squarespace, and GHL sites often have hidden dependencies. Classify each dependency as localized, replaced, removed because it is proven dead, or approved external runtime. Record the result in the manifest or dependency ledger.

Replace every lead form

Forms are one of the most important parts of the cutover because they are the path from the website to the client’s lead system.

Inventory every form placement, not just every form type. Look at contact pages, estimate forms, sidebars, footers, landing pages, popups, and multi-step forms.

For each form, record the fields, required states, labels, accessibility behavior, consent and privacy language, success behavior, current destination, recipients, workflow, tags, pipeline behavior, duplicate-contact behavior, spam protection, attribution requirements, and failure or fallback behavior.

Unless there is an approved exception, replace old WordPress or CMS-dependent forms with GoHighLevel forms in the correct client location. Preserve the existing field set, required behavior, layout footprint, accessibility, labels, error states, confirmation behavior, and mobile usability. Change fields only when there is a documented lead-handling, legal, spam-prevention, or usability reason.

Before live testing, confirm the workflow is published, recipients are correct, the embed is allowed on the production domain, CSP and iframe behavior permit it, CAPTCHA or spam protection is configured, consent and privacy language are approved, duplicate-contact behavior is understood, a deliberate failure fallback exists, and any required UTM or referrer data is captured.

On previews, test rendering, field validation, error states, width, spacing, and mobile behavior. Do not send a client-visible test until that exact action is approved.

Replace review widgets

Inventory every place the site displays reviews or testimonials. Some may be hard-coded editorial testimonials. Others may be live Google review widgets. Do not replace one type with the other without checking what the section is supposed to do.

Tekton’s standard live review option is Trustindex unless the project has an approved exception. Select the exact Google Business Profile using the verified business name and location. A compact carousel is usually the best fit because it updates automatically without taking over the page. Add a visible Leave a Review button when the widget supports it.

After installation, verify that it shows the right business, right location, correct reviews, working controls, and a usable mobile layout. Confirm the Leave a Review button points to the correct profile. Check width, spacing, and height on desktop, tablet, and mobile.

Automation can insert a widget into the wrong container, append it at the bottom of the page, miss the real review section, or leave the old widget visible. Visually inspect every review placement. Make sure no stale provider, wrong-location widget, duplicate widget, empty placeholder, or old hard-coded review block remains. Repeated widgets must not create a major performance or layout problem. Remove obsolete loaders, placeholders, and wrappers only after verifying they are no longer required.

Wrong-location reviews are a launch blocker.

Replace maps and other embeds

For every map, confirm the exact approved business location before creating the Google Maps embed. Then check that the map fills its container and behaves properly on desktop, tablet, and mobile. Test directions links and touch behavior.

Do the same for any other third-party embed. Some providers block preview domains. If that happens, confirm the direct provider URL and provide a deliberate fallback instead of leaving an empty box. Recheck the live domain after cutover.

Prepare redirects, but do not activate them yet

By this point the URL inventory should show which old routes need to move.

For every proposed redirect, record the source hostname and path, destination hostname and path, reason, evidence, whether content must be merged first, status code, matching mechanism, case policy, trailing-slash policy, query-string behavior, wildcard or parameter behavior, rule precedence, implementation platform, approval status and approver, preview result, live first-response result, and live final-destination result.

Possible implementations include Cloudflare Redirect Rules, Bulk Redirects, a Worker, a Pages _redirects file, or framework routing. Pick one method deliberately. Update internal links to point directly to the final URL instead of depending on redirects.

Preview-test the redirect behavior when possible, but do not activate live redirects until approval.

Phase 3 checkpoint

Every retained page should now exist on the immutable preview. The complete asset manifest should reconcile, npm run verify:clone-independence should pass, and source-origin blocking should produce zero unapproved runtime requests at desktop and mobile widths. Forms, reviews, maps, and embeds should have approved replacements. The redirect map should be complete enough that the team knows exactly what happens to every old URL.

Phase 4: Complete the initial optimization pass

This is the first cleanup pass, not the Core 30 buildout. Do not treat the headings below as separate bulk-edit assignments. Work page by page from the approved route inventory.

For each page, open the current live version, the proposed audit row, and the immutable preview together. Start with what the page is supposed to rank for and what action a visitor should take. Then review its metadata, H1, heading order, schema, canonical, internal links, images, and indexability as one connected page. A title change can affect the H1 decision. A redirect can change the canonical and sitemap. Looking at those items together prevents the site from ending up with technically valid pieces that disagree with one another.

Record the proposed page changes first. Have a human review the row, implement the approved set on the working branch, and check the rendered page on a fresh immutable deployment. Once the page passes, move to the next route. Run the sitewide duplicate and consistency checks after the page-level pass is complete.

The sections below explain what to look for during that page review.

Metadata

Run the first pass as a read-only proposal. For every retained canonical page, create one audit row with:

• Page URL
• Current meta title
• Proposed meta title
• Current meta description
• Proposed meta description
• Primary service or query theme
• Location target when appropriate
• Notes, risks, and approval status

The builder should not implement recommendations during the read-only audit. First scan the complete sheet for duplicates and obvious problems. Then closely inspect representative and high-value pages. Confirm that titles and descriptions are accurate, natural, service-relevant, location-appropriate, and supported by the page. Ask the builder or SEO reviewer to explain any recommendation that is unclear.

Review every retained canonical page. Check for duplicate titles, missing descriptions, wrong services, wrong towns, keyword stuffing, unsupported claims, and text that does not match the actual page.

The metadata should be clear and accurate. It should not promise services, service areas, experience, certifications, or results that the source material does not support.

H1s and heading structure

For every retained page, record the current H1, proposed H1, hierarchy issues, duplicate or missing headings, out-of-order headings, and approval status before implementation.

Each page should have one clear H1. The H1 must be accurate to the page, relevant to the service, appropriately localized, natural to read, and consistent with the metadata and search intent. It should not duplicate every keyword on the page.

Then check the H2 and H3 structure. Headings should describe the content hierarchy, not exist only because the old builder used heading tags for visual styling. Have the builder list every identified heading issue before changes are made.

Structured data

Review schema separately from the visible copy. Look for missing, invalid, duplicate, or conflicting markup. Confirm the correct business name, location, service, phone number, and URLs.

Captured sites often keep old-domain or preview URLs in schema. Those must be replaced with the approved production URLs before launch. Do not add unsupported ratings, service areas, claims, or entity relationships.

Canonicals and the preferred hostname

Do not automatically switch every site to non-www just because that is a common preference. First check what the current website enforces, what its canonical tags use, what the existing sitemap uses, and what Search Console and backlinks show.

Preserve the established hostname during a platform cutover unless a separate hostname migration is approved. Changing both the platform and canonical hostname at the same time creates extra redirects and extra SEO risk.

Every retained page needs a canonical that points to its preferred live URL. Redirect sources should not pretend to be active canonical pages. No production canonical should point to pages.dev, a branch preview, or the old host.

Sitemap, robots, and indexability

Build the new sitemap from the approved URL inventory. It can be generated during the build or stored as a reviewed static file, but it must not rely on old WordPress, Yoast, Rank Math, or previous-agency output.

Only include approved canonical, indexable URLs that return 200. Exclude redirects, retired pages, noindex pages, utility or intentionally excluded routes, soft 404s, preview URLs, and duplicate hostnames. If the sitemap uses <lastmod>, use real dates or omit the field.

Maintain an approved per-URL indexability field in the URL inventory. Do not noindex a page merely because it is legal, utility-oriented, or low traffic. Decide from the page’s purpose, search history, links, and approved policy.

Prepare separate search behavior for preview hosts and the approved production hostname. Unless an approved project exception says otherwise, production robots.txt should permit public-site crawling and include the live sitemap location. Verify the effective crawl policy rather than relying only on the file’s existence. Remember that crawlability and indexability are different: robots.txt controls crawling, while noindex controls index eligibility after a crawler can fetch the page.

Tekton may also publish /llms.txt and an intentional /llm.txt alias. /llms.txt is the canonical LLM-readable file. It should return plain text with a concise approved site description and an approved canonical-page list using the production hostname. It must not expose private, preview, retired, redirected, duplicate, excluded, or non-indexable routes. Configure /llm.txt as an intentional 301 redirect or equivalent alias. These files can support the approved AI-crawler policy, but they do not control Google indexing and do not replace robots.txt. Keep answer-agent access and AI-training policy as separate decisions.

Links, interactions, and real 404s

Run a global link sweep across the entire inventory. Check the header, footer, buttons, image links, phone numbers, emails, social links, review links, map links, forms, booking links, blog links, and unlinked legacy pages. Also catch empty href values, placeholder or hash-only traps, malformed URLs, inappropriate protocol-relative links, and links to removed routes. Record dead external links separately and decide whether to replace them, remove them, or document an approved exception.

Then test every interactive element. Open and close accordions. Use the mobile menu. Move carousels. Open galleries, tabs, modals, videos, and dropdowns. FAQ accordions deserve special attention because cloned markup can look correct while the open-and-close JavaScript no longer works. If the user can click, tap, slide, expand, submit, or play it, make sure it works.

Unknown URLs must return a real 404 or approved 410. A homepage displayed with HTTP 200 for every unknown path is a soft 404 and needs to be fixed.

Phase 4 checkpoint

Metadata, headings, schema, canonicals, sitemap routes, robots behavior, indexability, links, interactions, and 404 behavior should now be approved and working on the candidate deployment. Preview hosts must still be protected.

Before leaving this phase, request the candidate sitemap directly and verify HTTP 200, valid XML, production-host URLs, approved route count, and full reconciliation with the route inventory. Confirm that redirects, retired pages, noindex pages, preview URLs, duplicates, utility exclusions, and soft 404s are absent.

Phase 5: QA the exact deployment that may go live

This is the full prelaunch pass. Do not QA a moving branch URL and assume the final deployment is the same. Freeze one candidate commit and one immutable deployment, then test that exact version.

Check every retained route

Use the URL inventory as the test list. Every retained route needs a result, even when several routes use the same template.

For each route, verify the HTTP status, title, meta description, H1, canonical, indexability, schema, internal links, local assets, and visible page content.

Template checks are still useful. Make sure the set includes the homepage, contact page, every service and location template, blog index and article template, about/team pages, review pages, and every unique form or interactive section. But template sampling does not replace the route-by-route check.

Use a real device matrix

At minimum, test:

1. Desktop around 1280 pixels wide
2. A real phone using an approved browser
3. Tablet portrait around 768 pixels
4. Tablet landscape around 1024 pixels

If no physical tablet is available, Chrome DevTools or CDP emulation is acceptable. Record the device, operating system, browser, viewport, deployment URL, and date.

Look for horizontal overflow, clipped content, unreadable text, missing images, broken menus, awkward wrapping, tiny controls, and third-party embeds that do not resize. The page should never allow unintended left-to-right scrolling. If it can be swiped horizontally, identify the exact overflowing element and correct its width, wrapping, positioning, or container behavior. Retest that fix on a new immutable deployment using the real device.

Check the browser, not just the source

Open the console and network panel. Separate real site errors from known preview-domain blocks, but do not ignore unexplained failures.

Verify the rendered header, footer, navigation, forms, reviews, maps, media, accordions, carousels, tabs, modals, and other interactive pieces. A source file can look correct while the browser still renders a broken layout.

Decide whether the site is actually ready

These are launch blockers:

• Missing or wrong DNS information
• Unresolved DNSSEC risk
• Business email risk
• Wrong review or map location
• Missing retained route
• Broken primary navigation
• Failed critical form path
• Missing critical assets
• Certificate risk
• Redirect loops or bad redirect chains
• Wrong canonical hostname
• Unintended production noindex
• GitHub and Cloudflare pointing to different commits
• Old-host dependencies that will fail after cutover
• Severe mobile overflow or an unusable layout

A small spacing issue may be a non-blocker if it is documented and assigned. A broken lead form is not.

Phase 5 checkpoint

The team should now have one frozen candidate commit, one immutable deployment, a completed route ledger, device evidence, and no unresolved launch blockers. Reverify that the final approver, launch monitor, and rollback owner are available for the planned launch window.

Phase 6: Prepare Cloudflare DNS without moving the website

Cloudflare zone onboarding and Cloudflare Pages cutover are two different actions. Moving authoritative DNS to Cloudflare does not have to move the website yet. If the copied zone is correct, the old website can continue serving through the same origin records while Cloudflare becomes authoritative.

Add the domain to Cloudflare

The normal path is:

1. Open Domains.
2. Open Overview.
3. Select Add a domain.
4. Select Connect a domain.
5. Enter the root domain.

Cloudflare sometimes shows Please enter a valid domain even when the domain is valid. If that happens:

1. Open Build, then Workers & Pages.
2. Open the correct Pages project.
3. Open Custom domains.
4. Select Set up a custom domain.
5. Enter the domain and select Continue.
6. On Transfer DNS management, select Begin DNS transfer.
7. Select Connect and enter the domain again.

Cloudflare may ask how crawlers should be handled. Treat search crawlers, AI answer agents, and AI training as separate settings. Do not guess here. Use the crawler-policy decision recorded for the project. If the approved policy allows all three, the Cloudflare screen should show Search = Allow, Agents = Allow, Training = Allow, and Block training in robots.txt = off.

Import the correct DNS zone

First identify the authoritative provider. Then export from that provider.

If GoDaddy is authoritative, open the domain’s DNS screen, use the three-dot menu, and download the DNS zone file. Save the .txt file in the protected cutover evidence location. Do not include credentials, access tokens, recovery codes, or unrelated account information in the cutover record. In Cloudflare, open Import DNS records, choose Edit if shown, select DNS zone file, and upload it.

For other providers, use a full export when available. Cloudflare’s automatic scan is acceptable as a starting point, but it is not proof that every record was found.

Compare every record

Put the authoritative zone and Cloudflare side by side. Check type, name, value, priority, TTL, purpose, and proxy status for each record.

Do not import the old provider’s SOA record. Do not retain old apex authoritative NS records. Keep delegated subdomain NS records only when their purpose has been verified.

Proxy status deserves its own review. Mail and non-HTTP services are normally DNS-only. Review FTP, SSH, SIP, autodiscover, verification, and third-party service hosts. For website records, confirm the planned Cloudflare SSL/TLS mode, caching, and redirect behavior before turning the proxy on.

Also review CAA records to make sure Cloudflare can issue the required certificate.

Handle DNSSEC before changing nameservers

If DNSSEC is not active, record that fact and continue.

If the old provider has DNSSEC active, do not simply change nameservers and hope Cloudflare sorts it out. Use one of the documented migration paths for that domain:

1. Remove or disable the old DS record at the registrar.
2. Verify the old DS record is no longer published at the parent.
3. Change the nameservers to Cloudflare.
4. Wait until Cloudflare is authoritative and the zone resolves normally.
5. Enable Cloudflare DNSSEC.
6. Publish the new Cloudflare DS record at the registrar when Cloudflare requires it.
7. Verify DNSSEC with a validating resolver.

A pre-signed or multi-signer migration is also acceptable when the DNS operator has deliberately chosen and documented that method. Do not improvise it during launch.

If the old DS record is still present and does not match Cloudflare, stop. That can cause domain-wide SERVFAIL.

Prepare two rollback paths

A website problem and a DNS-authority problem are not the same thing.

For a website-only failure, the fastest cutback is usually to restore the previous web A, AAAA, or CNAME record inside the active Cloudflare zone. This leaves email and the rest of DNS alone.

For a zone-wide failure, the authority rollback is to restore the old nameservers. This is slower and should only be used when the old authoritative zone still exists and is known to be correct.

Record the previous nameservers, old web-origin records, source zone, proposed Cloudflare nameservers, email records, registrar and Cloudflare access confirmation, expected TTL, caching and propagation limits, planned change time, approver, rollback trigger, decision owner, execution owner, and post-rollback checks. Keep the old website available during stabilization.

Change the nameservers

Only do this after DNS parity, DNSSEC review, rollback preparation, and exact approval.

1. In Cloudflare, select Continue to activation.
2. Copy the two Cloudflare nameservers from Update your nameservers to activate Cloudflare.
3. Replace the current nameservers at the registrar.
4. Save the change.
5. Return to Cloudflare and select I updated my nameservers.

Cloudflare may temporarily show Invalid nameservers. Do not treat a ten-minute estimate as a deadline. Verify the parent delegation, query each Cloudflare authoritative nameserver directly, and check multiple recursive resolvers.

Confirm SOA and NS answers, the web records, MX, SPF, DKIM, DMARC, critical subdomains, third-party verification records and DNS-dependent applications, and DNSSEC validation.

Once Cloudflare is active, verify that the old website still loads and that business email still works. If authorized, run inbound and outbound mail tests. This is the proof that DNS authority moved without breaking the business.

Phase 6 checkpoint

Cloudflare should now be authoritative while the existing website and email continue working. Do not attach the Pages domain until that continuity is proven.

Phase 7: Put the approved build on production

Before the domain can point to Pages, GitHub and Cloudflare must agree on the exact production build.

After production-deployment approval:

1. Confirm the approved working-branch commit.
2. Merge or push that exact commit to the configured production branch.
3. Confirm the GitHub production branch points to the approved SHA.
4. Let the project’s configured deployment method run. Use either the Git integration or the approved direct-upload method, not both.
5. Record the Cloudflare deployment ID and immutable production URL.
6. Confirm Cloudflare built the same commit or exact artifact.

Open the immutable production deployment and the stable Pages project URL. Check images, forms, review widgets, maps, navigation, shared styles, scripts, sitemap, robots behavior, and preview protection again.

If GitHub and Cloudflare do not match, stop. Do not attach the live domain to a build you cannot identify.

Phase 8: Attach the live domain

This is the point where website traffic moves to Cloudflare Pages. It requires its own approval.

Attach the primary hostname

1. Open Build, then Workers & Pages.
2. Open the correct Pages project.
3. Open Custom domains.
4. Select Set up a custom domain.
5. Enter the approved primary hostname.
6. Select Continue.

Cloudflare may ask to replace an existing A or CNAME record. Before accepting, confirm the current record, the Pages project, and the rollback value. Wait until the custom-domain and certificate status are active.

Then attach the alternate hostname, usually the other version of apex or www:

1. Stay on the same Custom domains tab.
2. Select Add a custom domain, Set up a custom domain, or the current equivalent.
3. Enter the approved alternate hostname.
4. If Cloudflare asks to replace an existing A or CNAME, confirm the target project, existing record purpose, and rollback value before accepting.
5. Wait until the alternate mapping and certificate are active.
6. Confirm both hostnames show an active state before configuring the hostname redirect.

Enforce one hostname

Adding both hostnames to Pages does not automatically prove one redirects to the other.

Use an approved Redirect Rule, Bulk Redirect, Worker, or other host-aware mechanism. Test the first response without automatically following it. Confirm a permanent 301 or 308, the exact destination, path preservation, query-string behavior, and the absence of loops or chains.

Preserve the existing canonical hostname unless a separate hostname migration was approved. If the old site does not establish a preference, the team may choose the non-www apex, but that choice still needs approval.

Turn on the approved route redirects

Activate only the approved redirect map. Check every important source URL and confirm the first response and final destination. Internal links should already point directly to the destination.

Phase 9: Run the immediate live check

Use an incognito or guest browser to reduce browser cache and cookie issues. Incognito does not clear DNS caches, so verify DNS with direct lookups as well.

Start with the approved primary hostname. Confirm it serves the correct Pages deployment over HTTPS. Then check the alternate hostname redirect.

Open the homepage, contact page, one important service page, one location page, and any other critical conversion page. Check images, fonts, scripts, navigation, mobile menu, forms, reviews, and maps. Use a real phone for the mobile check.

Open the browser console and network panel on the live hostname. Investigate unexplained script, asset, API, CSP, mixed-content, and request failures before activating search visibility.

Check business email and critical subdomains again.

Prove the critical lead path before opening the site to search

The form may render correctly and still fail after the live domain is attached. Before removing production noindex or submitting the sitemap, get approval for a small live smoke test.

Use labeled synthetic data and submit at least one form from every critical lead path. Confirm the browser success state, the contact inside the correct GoHighLevel location, the expected workflow, and the intended internal notification. If the client notification must remain suppressed until the full form test, document that exception and prove the internal CRM path first.

Do not make the site indexable while the main lead path is still unproven.

If the wrong site appears, the certificate fails, email breaks, critical assets are missing, primary navigation is broken, a redirect loop appears, the critical lead path is unusable, or indexability is unsafe, stop and use the rollback path that matches the problem. Prefer the website cutback when DNS itself is healthy.

Phase 10: Activate search visibility

Check Search Console before creating anything

Look for an existing Domain property under the approved Google accounts. Preserve existing ownership, users, and historical data. Also note any URL-prefix properties because they may contain useful history.

Request delegated access when appropriate. Create a new Domain property only when there is no suitable existing property or policy requires a new one. A Domain property can be verified after Cloudflare becomes authoritative; it does not have to wait for the Pages hostname attachment.

Verify the Domain property

After approval:

1. Open Search Console under the correct Tekton account.
2. Open the property selector.
3. Select Add property only if needed.
4. Choose Domain, not URL prefix.
5. Enter the domain without the protocol or path.
6. Use the Cloudflare verification flow when offered.
7. Confirm the Google TXT record appears in authoritative Cloudflare DNS.
8. Confirm Search Console reports verified ownership.

Make only the live hostname indexable

The best setup is host-aware: the approved live hostname serves the production indexability configuration, while pages.dev, branch previews, immutable previews, and staging hosts stay noindex or access-protected.

If the current project can only switch noindex globally, use a controlled two-step launch. Remove the global noindex immediately after the live hostname is verified, redeploy the exact approved production configuration, and prove GitHub/Cloudflare parity again.

Check the HTML meta robots tag, X-Robots-Tag response headers, framework configuration, Cloudflare _headers, and per-route exceptions separately. One correct setting does not cancel a conflicting noindex somewhere else.

Validate the live support files

On the approved hostname, confirm:

• robots.txt returns 200 and contains the approved crawl policy.
• The sitemap returns valid XML.
• The sitemap returns HTTP 200.
• The sitemap includes only canonical, indexable 200 URLs.
• The sitemap route count reconciles with the approved inventory, and every approved sitemap route is present.
• Sitemap hostnames match the approved canonical hostname.
• Redirect sources, preview URLs, retired pages, and noindex pages are absent.
• Canonical tags use the approved production URLs.
• Unknown URLs return a real 404 or approved 410.
• /llms.txt returns HTTP 200 as plain text, and the /llm.txt alias works as approved when the project requires them.

Submit the sitemap

After approval, open Sitemaps in the correct Search Console property and submit the new static sitemap path. Make sure it is the new sitemap, not an old WordPress, Yoast, or Rank Math path. Save the submission timestamp and screenshot or response evidence.

Search Console may report accepted, pending, successful, or an error. If it shows an error, open the detail before resubmitting. Sometimes the detail shows successful processing while the list view is stale. If the sitemap is valid but still processing, assign a follow-up owner rather than submitting it repeatedly.

The submission is not complete merely because the form accepted the URL. Recheck until Search Console shows successful processing or until the documented follow-up owner resolves the error. When Google reports discovered pages, compare that number with the approved route inventory and investigate unexplained differences.

Phase 11: Run the full live QA

Now repeat the route-level audit against the real domain.

Crawl every sitemap URL. Check the status, title, H1, canonical, schema, and indexability. Run the internal-link sweep again. Verify redirects without hiding chains. Check images, interactions, desktop, real-phone mobile, and tablet when practical.

Open the browser console and network panel. Confirm there are no old-host URLs in metadata, schema, or required assets.

Test the live forms end to end

Once live form testing is approved, use clearly labeled synthetic data.

Test every distinct form configuration and every critical lead path. For each submission:

1. Record the live URL and form placement.
2. Submit the approved test identity.
3. Confirm the browser success or thank-you behavior.
4. Confirm the contact appears in the correct GoHighLevel location.
5. Confirm the workflow ran.
6. Confirm the expected tags and pipeline stage.
7. Confirm internal alerts.
8. Confirm the intended client notification.
9. Confirm attribution fields when required.
10. Save the timestamp and evidence.

A form is not verified just because the page displayed a success message. The CRM entry and intended notification must exist. After the test, remove or clearly tag synthetic contacts, opportunities, and pipeline records according to the approved cleanup method so tests do not pollute the client’s reporting. Preserve the test evidence before cleanup.

Phase 12: Monitor and close out

Check the site at launch, around one hour, around 24 hours, and again between 48 and 72 hours. Give every monitoring window a named owner and exact timestamp.

During each check, review DNS delegation, DNSSEC, certificates, website availability, business email, critical subdomains, redirects, forms, 404 and server errors, old-host dependency failures, Search Console, sitemap status, unexpected indexing of protected hosts, and unexpected noindex behavior. If a check fails, mark it FAIL - BLOCKER or FAIL - NON-BLOCKER, notify the launch owner and rollback owner, and record whether the site was fixed forward or rolled back.

Keep the previous website available through the approved stabilization and rollback-retention window. Completing the 48-to-72-hour monitoring checkpoint does not, by itself, authorize shutdown. Retire the old host only after stabilization is complete, the rollback owner releases the old site, and the shutdown has been approved.

Treat old-host retirement as two separate closeout actions:

1. Technical retirement: confirm the new site no longer depends on the old origin, export and retain the approved backup, and document how rollback will work after shutdown.
2. Commercial cancellation: stop the obsolete hosting subscription or plan so the client is not billed for unused website hosting.

Before either action, identify the provider, account owner, cancellation owner, renewal date, billing cycle, bundled services, and exact scope being canceled. Do not cancel domain registration, authoritative DNS, business email, mailboxes, Microsoft 365 or Google Workspace, unrelated websites, CDN/storage used by the new site, or any bundled service unless that exact dependency has been inventoried and separately approved.

Hosting cancellation is a billing/subscription action and requires Nick’s exact approval before Tekton executes it. Use APPROVE HOSTING CANCELLATION: <client> / <provider> / <plan or site> so the scope is unmistakable. If the client owns the account and must cancel it, obtain approval for the client update, send precise instructions, and keep the item open until the client provides cancellation confirmation. Technical retirement is not proof that billing stopped.

The closeout packet should contain:

• Live primary URL
• Alternate-host redirect result
• GitHub repository and production branch
• Approved commit SHA
• Cloudflare deployment ID
• Immutable production deployment URL
• Stable Pages project URL
• DNS parity and nameserver evidence
• Nameserver activation time
• DNSSEC and certificate results
• Route inventory and final dispositions
• Redirect report
• Exact sitemap URL and sitemap-processing result
• Robots, canonical, noindex, X-Robots-Tag, status-code, and optional LLM-file results
• Search Console property and sitemap status
• Desktop, phone, and tablet QA evidence
• Live form-test results
• Monitoring log
• Remaining non-blockers and owners
• Rollback status and rollback-owner release
• Old-host provider, account owner, plan/site, renewal date, and cancellation owner
• Bundled-service dependency review and retained backup/archive location
• Technical-retirement approval, result, and post-retirement verification
• Hosting-cancellation approval, confirmation/reference, effective date, and final invoice/refund status
• Final approver signoff

The cutover is complete when the live website works, email still works, leads reach the right place, search settings are correct, every known URL has an intentional outcome, and the evidence packet proves it. If the approved rollback-retention window extends beyond launch QA, report LAUNCH COMPLETE - OLD-HOST CLOSEOUT PENDING until technical retirement and commercial cancellation are evidenced. Do not issue final project signoff while obsolete hosting billing is unconfirmed or unassigned.

Do not close the cutover while a blocker is undocumented or unresolved. Every blocker must be resolved, rolled back, or explicitly accepted by an authorized approver with the reason and evidence recorded before final signoff.

Required project records

The walkthrough above explains the work. The following records make it reviewable and repeatable. They may live in one workbook, several project files, or an approved operating system, but every required field must exist.

Old-host closeout record

For repository-backed website work, create docs/cutover-closeout.md unless an equivalent approved launch record already exists. Keep the record open until the old-host subscription is confirmed canceled or a client-owned cancellation has a named owner and documented confirmation request. Include:

• production URL, commit/deployment, launch timestamp, launch owner, and rollback owner;
• launch, one-hour, 24-hour, and 48-to-72-hour checkpoint owners, timestamps, results, and evidence;
• the approved rollback-retention deadline;
• old provider, account owner, exact plan/site, renewal date, billing cycle, bundled-service review, and cancellation owner;
• backup/archive location and retention owner;
• rollback-owner release and exact shutdown approval;
• technical-retirement action, timestamp, result, and verification;
• exact hosting-cancellation approval;
• cancellation confirmation/reference, effective date, final invoice/refund status, and post-cancellation billing verification;
• proof that domain registration, DNS, business email, unrelated sites, and unapproved bundled services remain intact;
• final approver signoff and any remaining exceptions with owners.

URL inventory and decision ledger

For every discovered URL, record:

• Current URL and page type
• Discovery source, such as CMS, sitemap, crawl, Search Console, analytics, backlink data, or archive
• Current HTTP status and canonical
• Indexability
• Search Console clicks, impressions, and useful queries when available
• Backlinks, internal links, and known conversions when available
• New route
• Disposition: retain, keep for later improvement, merge and redirect, redirect, retire, or investigate
• Redirect destination and status when applicable
• Decision rationale
• Owner, approval status, and unresolved risk
• Preview result and live result

DNS and email ledger

For every active or required record, capture:

• Record type
• Name or host
• Value or target
• Priority
• TTL
• Proxy status
• Purpose
• Source authoritative provider
• Cloudflare imported value
• Parity result
• Notes or exception

Keep separate evidence for active nameservers, old and new DNSSEC or DS state, MX, SPF, DKIM, DMARC, CAA, critical subdomains, and the final authoritative resolver checks.

Redirect ledger

For every redirect, include:

• Source hostname and path
• Destination hostname and path
• Reason and supporting evidence
• Whether content was merged first
• Status code
• Case, slash, query, wildcard, and parameter handling
• Rule precedence and implementation platform
• Approval and approver
• Preview result
• Live first-response status and Location
• Live final destination and chain result

Form and lead-path ledger

For every distinct form configuration and critical placement, record:

• Live route and placement
• Correct GoHighLevel location
• Form or embed identifier
• Fields, required states, consent text, and success behavior
• Recipients, workflow, tags, and pipeline stage
• Spam protection and attribution behavior
• Preview render and validation result
• Approved live test identity and approval record
• Browser success result
• CRM contact result
• Workflow and notification result
• Test-data cleanup result
• Timestamp and evidence

Deployment and QA ledger

For every review or production build, capture the branch, commit SHA, Cloudflare deployment ID, immutable URL, stable URL, build result, preview-protection result, device or viewport, route set tested, console and network result, issue list, and retest status.

For each defect, record expected and actual behavior, severity, owner, screenshots or recordings, correction commit, exact immutable deployment, and final retest result.

Approval and rollback ledger

Each live approval should record the exact approval phrase, approver, timestamp, domain or project, exact action, commit or artifact, launch window, rollback owner, and related evidence packet.

The rollback record should include the old nameservers, old web records, source zone, Cloudflare nameservers, email records, DNSSEC state, access confirmation, TTL and caching limits, triggers, decision owner, execution owner, old-host availability, and post-rollback checks.

Security and data-handling rules

Keep repositories, evidence packets, DNS exports, screenshots, and form tests at the approved access level. Do not place passwords, recovery codes, API tokens, private client data, or unrelated account details into code, tickets, screenshots, or review packets. Use labeled synthetic identities for approved form tests and clean those records up after evidence is preserved. Confirm authorization before copying code, content, or assets from a client’s existing website.

Quick launch checklist

Use this list as the final go/no-go check. It does not replace the process above.

Before DNS or production

• Complete URL inventory reviewed
• Every URL has an approved disposition
• All retained routes pass immutable-preview QA
• Required images are self-hosted
• Forms, reviews, maps, links, and interactions pass
• Desktop, real-phone mobile, and tablet checks pass
• Metadata, H1s, schema, canonicals, sitemap, robots, and 404 behavior pass
• Production commit and immutable deployment are frozen
• Authoritative DNS zone and email records are captured
• DNSSEC, CAA, proxy, SSL/TLS, and rollback plans are reviewed
• Old website remains available
• Separate live approvals are recorded

During launch

• Cloudflare DNS zone matches the authoritative source
• Cloudflare nameservers become active
• Existing website and email still work after authority transfer
• GitHub production and Cloudflare Pages match the approved commit
• Primary and alternate hostnames have active certificates
• Hostname redirect returns the approved permanent status
• Approved route redirects work without loops or chains
• Immediate desktop and real-phone checks pass

Search and lead systems

• Existing Search Console ownership was checked first
• Domain property is verified
• Live hostname has the approved indexability configuration
• Preview hosts remain protected
• Robots, sitemap, canonicals, status codes, and optional LLM files pass
• Sitemap submission is accepted or assigned for follow-up
• Live forms create the expected GoHighLevel contact and workflow result
• Intended notifications are received

Closeout

• Full live route crawl passes
• Launch, one-hour, 24-hour, and 48-to-72-hour checks are recorded
• Evidence packet is complete
• Remaining non-blockers have owners
• Rollback status and rollback-owner release are documented
• Old-host provider, account owner, plan/site, renewal date, billing cycle, bundled services, and cancellation owner are recorded
• Approved backup/export is retained and the new site has no dependency on the old origin
• Technical retirement has exact shutdown approval and verification evidence
• Obsolete hosting billing is canceled or assigned to the client, with confirmation/reference, effective date, and final invoice/refund status recorded
• Domain registration, DNS, business email, unrelated sites, and unapproved bundled services remain intact
• Final signoff is recorded