A Practical Runbook for Moving a Static Site Without Missing Critical Checks

A dependable static website migration checklist has seven phases: classify the move, back up and inventory the existing site, audit static-specific dependencies, validate the generated release, preserve URL behavior, execute the DNS and HTTPS cutover, and monitor the result. Treat launch as a controlled release with named owners, evidence-based acceptance criteria, and a working rollback—not as a DNS change followed by hope.

Start here: classify the migration and assign owners

First, identify what is changing. A project may belong to more than one class, but each class adds a distinct branch to the checklist.

Migration class	Main risks	Required emphasis
Same-URL hosting or CDN move	DNS errors, crawler blocks, missing assets, configuration differences	Copy, staging tests, DNS, HTTPS, crawler access, logs, delayed retirement
Domain or path change	Broken links, poor redirects, conflicting URL signals	URL mapping, permanent redirects, updated references, monitoring both URL sets
Generator or platform replacement	Route drift, metadata changes, broken publishing	Output parity, build validation, integrations, editorial workflow, rollback
Dynamic-CMS-to-static conversion	Lost request-time behavior or publishing capabilities	Fit assessment, dependency decisions, hybrid delivery where necessary

A same-URL infrastructure move normally needs neither a new redirect map nor Search Console’s Change of Address tool. It still requires a tested copy of the site, controlled DNS changes, preserved verification, confirmed crawler access, and monitoring across the old and new infrastructure.

A domain or path change requires old-to-new URL mapping, permanent redirects, updated internal references, and observation of both URL sets. When practical, avoid combining a domain move, generator replacement, redesign, and content rewrite in one release. Separating major changes makes failures easier to diagnose, although scope, staffing, and operational constraints determine the final sequence.

For a dynamic-to-static conversion, assess architectural fit before choosing an exporter or generator. Authentication, checkout, accounts, personalization, and dashboards rely on request-time behavior and may justify hybrid delivery rather than a fully static site. Preview links, webhooks, scheduled tasks, search indexes, and other less visible dependencies need the same scrutiny.

Use a responsibility table as an operating method, not as a search-engine requirement:

Task	Owner and deadline	Evidence and acceptance criterion	Rollback impact
Validate route inventory	Engineering; before release freeze	Manifest comparison attached; required routes accounted for	Block launch
Approve redirect map	SEO/content; before cutover	Old-to-new tests pass; destinations approved	Restore previous rules
Confirm publishing workflow	Editorial; before go/no-go	Preview, approval, publish, and recovery tests pass	Retain old workflow
Authorize launch	Named authority; cutover window	Blocking criteria closed or explicitly accepted	Invoke rollback owner

Give each critical task one accountable owner. “Engineering” or “marketing” may identify the responsible group, but the launch runbook should also name the person who can make the decision.

Before building: back up, inventory, and record a baseline

Create restorable backups of:

• source content and media;
• repository or project files;
• generator, host, and environment configuration;
• current DNS values;
• redirect and rewrite rules;
• analytics, consent, tag, and verification setup;
• the last known-good deployment or release artifact.

Next, create a master inventory. Begin with a crawl, then supplement it with XML sitemaps, analytics landing pages, Search Console data, server logs, backlink reports, campaign links, and stakeholder input where available. No single source reliably reveals every orphaned, historical, or externally linked URL.

Inventory more than HTML pages. Include images, JavaScript, CSS, fonts, feeds, PDFs and other downloads, media files, archive pages, pagination, multilingual paths, custom error pages, and assets referenced by campaigns or third-party sites.

A practical working URL manifest is:

Identity and destination	Expected behavior	Search requirements	Context and result
Old URL; expected new URL	Expected status	Canonical; indexability	Priority; traffic or backlink context; owner; test result

Add content-type or locale fields if they make review easier. For unchanged routes, the old and expected new URLs can match. For removed content, record the intended 404 or 410 response instead of leaving the destination ambiguous.

Capture a baseline suited to the project. Useful measures include traffic, rankings, conversions, indexed URL counts, status-code distribution, crawl behavior, page performance, and high-value landing pages. The purpose is to distinguish migration regressions from pre-existing conditions—not to impose a universal retention target.

Also document:

• the migration objective and scope;
• launch authority and the incident communication path;
• the rollback owner and mechanism;
• which unresolved issues are launch blockers;
• which defects may be accepted temporarily;
• where evidence for each decision will be stored.

Backups are only useful if they can be restored. Confirm access, permissions, and recovery steps before the release window.

Audit what static delivery changes

A CMS-to-static move changes architecture and editorial operations, not merely hosting. Inventory every feature that expects a server, database, logged-in user, scheduled process, or request-time response:

• forms, comments, and site search;
• authentication, accounts, ecommerce, and gated content;
• personalization and AJAX endpoints;
• editorial previews and draft access;
• feeds, webhooks, and scheduled tasks;
• redirects generated by the former CMS;
• media transformations and third-party integrations.

Give each dependency one explicit disposition: replace it with an external or client-side service, retain a narrow dynamic component, redesign the experience, or remove the feature. Record the owner, implementation decision, and acceptance test. This is architectural guidance rather than a universal requirement; the correct choice depends on the site’s actual runtime and editorial needs.

Document how editors will preview drafts, request approval, trigger builds, schedule publication, release urgent corrections, and recover from a failed deployment. Test permissions and failure paths as well as the happy path. A workflow that publishes successfully under ideal conditions is incomplete if editors cannot diagnose or reverse a failed build.

Generate the first complete build and treat the output as a production release candidate. Compare its route list with the master inventory. Run end-to-end tests for navigation, forms, search, downloads, analytics, consent behavior, media, feeds, archives, integrations, and the publishing workflow.

Do not assume static delivery is inherently faster, safer, cheaper, or more search-friendly. Those outcomes depend on the build, delivery architecture, third-party services, cache configuration, operational practices, and implementation quality.

Validate the staging release, not just the source files

Use a restricted staging or preview environment. Authentication or equivalent access controls should protect staging; if public testing is necessary, add a temporary noindex directive as a secondary safeguard. Do not treat robots.txt as access control, and make verification of production crawlability a launch task (staging access-control guidance).

Crawl the generated deployment and compare it with the manifest. Check:

• routes, status codes, page content, titles, descriptions, and headings;
• canonicals, structured data, hreflang, and indexability;
• XML sitemaps and robots directives;
• internal links, archives, pagination, and media URLs;
• images, scripts, stylesheets, fonts, feeds, and downloads;
• desktop and mobile layouts, including loading states.

Run the reusable functional suite against forms, search, analytics events, consent behavior, downloads, and third-party integrations. At this phase, the purpose is to prove that the release artifact works before public configuration or traffic is involved.

Test crawler access deliberately while ensuring that staging hostnames, authentication rules, noindex headers, or blocked asset paths cannot be carried into production. Staging protections should remain on staging after launch; only staging-specific restrictions mistakenly present in the production release should be removed.

Visual review should cover loading behavior, not only settled screenshots. In Impetuous AI’s first-party audit, settled captures missed text movement caused by delayed font loading, so the process now records font timing and layout movement across desktop, phone, and WebKit checks. That work demonstrated a rendering improvement, not a ranking, traffic, conversion, or revenue improvement (Impetuous AI).

Define a project-specific go/no-go gate. Proposed criteria include:

• no unresolved production crawl or indexing block;
• every required route present;
• priority journeys and integrations working;
• tracking and consent behavior validated;
• URL and redirect tests passing;
• public DNS and HTTPS configuration prepared;
• rollback tested and available.

These are operating criteria, not universal thresholds. A failed critical journey or an unknown rollback path should stop the launch even when most checklist rows are green.

Preserve URL behavior and search signals

For every unchanged URL, request the release candidate using the expected public path and verify that it returns the intended successful page. Compare the resulting route, response, content, canonical, and internal references with the manifest rather than assuming that generated filenames prove parity.

For changed URLs, map each old page to a relevant final destination and use a direct server-side permanent redirect, normally HTTP 301 or 308. Avoid loops and unnecessary chains, and incorporate existing legacy redirects into the new map. If deleted content has no suitable replacement, return 404 or 410 rather than redirecting it to an unrelated category or the homepage. Google’s URL-changing site-move documentation calls for testing the new site, mapping URLs, enabling redirects, and monitoring both locations.

Update internal links, canonicals, hreflang annotations, XML sitemaps, campaign links, email links, and other controlled references so they point directly to final URLs. Redirects should protect old requests, not become the site’s normal internal routing layer.

Apply the same discipline to static assets and downloads. Images, scripts, stylesheets, videos, feeds, and documents may have indexed URLs, external links, or hard-coded references even when the page routes remain unchanged.

Verify all relevant Search Console properties. Use Change of Address only for applicable domain or subdomain moves—not ordinary HTTP-to-HTTPS changes, www changes, same-domain path changes, or same-URL hosting moves. Sitemap submission can assist discovery, but it cannot replace redirects, correct internal references, or crawler access.

Run the DNS, CDN, HTTPS, and launch-day cutover

Before cutover, export or record the complete DNS configuration. Distinguish web-serving A, AAAA, and CNAME records from MX, TXT, verification, email, API, and other records. Change only what the migration requires.

If the authoritative DNS service permits TTL changes, consider lowering the relevant TTL in advance so cached answers expire sooner. Choose the value according to provider controls, resolver behavior, risk tolerance, and the rollback plan rather than applying one number to every environment.

If Cloudflare is in the path, decide whether each compatible web record should be proxied or DNS-only. This is Cloudflare-specific: A, AAAA, and CNAME records can be proxied, while records such as MX and TXT remain DNS-only. Test SSL mode, CNAME behavior, caching, request limits, and origin timeouts before cutover (Cloudflare proxy-status documentation).

During cutover:

1. Deploy the exact release candidate.
2. Enable the approved redirects and headers.
3. Update only the necessary DNS records.
4. Confirm that production does not contain staging authentication, noindex, or unintended crawl blocks.
5. Test public DNS from outside the deployment environment.
6. Check priority pages, redirects, canonicals, robots directives, and sitemaps.
7. Run the critical functional suite and confirm public analytics events.

The staging environment should remain restricted. The launch task is to remove staging-only controls from production—not to expose staging itself.

Configure a valid certificate and working HTTPS before enabling HSTS. Permanently redirect accepted HTTP traffic to HTTPS, then send the HSTS header only over HTTPS. Use includeSubDomains only when every covered subdomain supports HTTPS. Preload is optional and difficult to reverse, so it should not be a default launch-day checkbox. Browsers remember an HSTS policy and do not permit users to bypass certificate errors for covered hosts (MDN’s HSTS reference).

Keep the previous deployment, recorded DNS values, redirect configuration, and last known-good artifact available. Rollback criteria should reflect the project’s critical journeys and risk rather than an unsupported universal traffic percentage or time window.

Monitor the move and retire the old deployment by evidence

Immediately crawl the live site and manually test the highest-priority pages and journeys. At this phase, the purpose is no longer to prove the build in isolation; it is to confirm that public DNS, certificates, redirects, production headers, third-party services, and real traffic behave as expected.

Monitor:

• public DNS, uptime, and certificate validity;
• 2xx, 3xx, 4xx, and 5xx responses;
• broken links and unexpected 404s;
• crawl errors, crawler access, and indexing;
• traffic, rankings, conversions, and page performance;
• priority landing pages and publishing reliability.

For a same-URL hosting move, compare old and new server logs as traffic shifts. Google says a temporary fall in Googlebot crawl rate can occur after such a move and may recover if the new infrastructure remains accessible and responsive. Keep the old infrastructure available until its traffic reaches zero and requests are being served by the new environment (Google’s same-URL hosting guidance).

For a URL-changing move, processing occurs URL by URL as old and new locations are crawled. Temporary ranking or indexing fluctuations may occur, and neither complete traffic retention nor a fixed recovery date is guaranteed. Retiring the old content deployment does not mean abandoning the old URLs: the old domain or routing layer must continue answering those requests with the approved redirects.

Branch the retirement decision by migration class:

• Same-URL infrastructure move: retire the old host only after its traffic reaches zero and the replacement has demonstrated stable access.
• URL-changing move: retire obsolete content-serving infrastructure only after confirming that a durable redirect service remains available for old URLs.
• Generator replacement: preserve the previous artifact and configuration until the new publishing and recovery workflows are stable.
• Dynamic-to-static conversion: confirm that every retained dynamic or hybrid component is observable and supportable.

Before closing the project, verify that priority journeys are stable, redirects remain direct and valid, analytics and conversion tracking work, crawler access and indexability are correct, and the previous deployment and configuration have been archived in an access-controlled rollback package.

The migration is not complete when DNS changes. It is complete when the release is validated, URL behavior is correct, integrations work, crawler and user access are observable, and enough infrastructure remains to recover when necessary. Copy the phase checklist into the project tracker and attach evidence to every acceptance criterion.

Does a same-URL static hosting move require Google Search Console’s Change of Address tool?

No. Change of Address is for eligible domain or subdomain moves, not a hosting or CDN migration that preserves user-visible URLs. For a same-URL move, preserve Search Console verification, test crawler access, update DNS, monitor the old and new infrastructure, and retain the old host until its traffic reaches zero (Google Search Central).

Should HSTS preload be enabled during the migration?

Usually not as a default migration step. First make HTTPS and certificate management reliable, redirect accepted HTTP requests permanently to HTTPS, and introduce HSTS cautiously. Consider preload only after every covered subdomain is HTTPS-ready, the preload requirements are satisfied, and the team accepts that reversal can be slow and operationally difficult.