Capture Before You Migrate. Why the New Site Should Boot Up Functionally Equivalent

Most site migrations start from a blank Eleventy or Hugo template, then slowly rediscover what the old site had over a period of weeks. The consent banner gets forgotten for two days. The GA4 tag gets installed with the wrong property ID. The sitemap structure changes silently and nobody notices until rankings drop. The Site Migration Capture tool exists to stop that pattern.

You paste your source URL, pick a target generator (Eleventy, Hugo, Astro, Gatsby, Next.js static export, Jekyll, Nuxt static export, or SvelteKit static adapter), and the tool captures a manifest of the source site's settings footprint. Framework detected, plugins detected, active theme, consent vendor, tracking stack, link graph from the homepage, sitemap and robots.txt and ai.txt presence, web fonts, JSON-LD blocks. Then it emits a spawn prompt that includes the full manifest as JSON, so the target-generator starter project can be generated with behavior equivalent to the source.

What the capture contains

• Identity: title, meta description, canonical, lang, H1, first 20 H2 headings. Enough to verify the new site's metadata matches the old.
• Platform: generator meta, active theme (for WordPress-style detection), detected framework list with family classification (CMS, ecommerce, SSG, Jamstack, builder, headless).
• Aux files: presence of robots.txt, ai.txt, sitemap.xml, llms.txt, manifest.json, wp-json, RSS feed. Each is a file the migration needs to reproduce or explicitly decide not to reproduce.
• Privacy and consent: which consent vendor is active (Cookiebot, OneTrust, CookieYes, Complianz, Borlabs, Iubenda, Termly, Cookie Script, Osano). Changing consent vendor mid-migration is a legal event, not a design event.
• Tracking and ads: GTM, GA4, Meta Pixel, Hotjar, Clarity, AdSense, Google Ads, Segment, Mixpanel, Amplitude. Each one has a property ID or container ID that must match on the new site or you lose continuity.
• Link graph snapshot from the homepage. Every internal link and external link with anchor text. Lets you rebuild navigation and spot orphans.
• JSON-LD schema blocks on the homepage.
• Web fonts loaded from Google Fonts (most common vector).

What the spawn prompt produces

Pick Eleventy and the prompt asks for: project file tree, _data/site.json, base.njk layout, .eleventy.cjs config, package.json, robots.txt/ai.txt/sitemap.xml/llms.txt reproduced from the manifest, analytics and tracking injected (only the vendors the manifest showed were present, not invented ones), consent banner wiring if a vendor was detected, schema JSON-LD ported from the source, and a content-import strategy appropriate for the source. WordPress source gets WXR-export instructions. Shopify source gets Storefront API export. Static source gets a crawl-and-scrape approach.

Pick Hugo, and the prompt asks for the equivalent Hugo file tree with config.toml, layouts/_default/baseof.html, and the same aux-file reproduction. Same for Astro, Gatsby, Next.js static export, Jekyll, Nuxt, and SvelteKit static adapter.

The prompt is explicit about what not to do: don't invent tracking IDs, don't hardcode API keys, preserve URL structure so redirects aren't needed, emit redirects in the target platform's native format if structure must change, call out every silent-break risk.

What it won't capture

Anything behind login. Anything generated server-side that leaves no trace in rendered HTML. Custom CMS plugins that only expose admin UI. Database state. Hosting-tier specifics (redis, varnish, reverse proxies). Search indexes. Staff accounts. CDN rules. Payment processor integrations that expose nothing but an iframe.

For those, the capture manifest is a starting point, not a finished migration plan. The spawn prompt explicitly asks the model to call out features that need manual re-implementation and features that silently break without warning.

The workflow, end to end

1. Run the capture against the source site. 10 seconds, returns a JSON manifest and a spawn prompt.
2. Paste the spawn prompt into Claude or ChatGPT. 60 seconds, returns a starter project.
3. Clone the starter project locally. Run its dev command. Verify it renders.
4. Run the source URL and the new localhost URL side by side. Diff the visible pages, the meta tags, the schema blocks.
5. Port content using the import strategy the spawn prompt suggested.
6. Deploy the new site to staging. Point a test subdomain at it. Verify GA4, consent banner, sitemap, robots.txt are live and correct.
7. Cut over DNS.

Total elapsed time for a small-to-medium content site: 4 to 12 hours. Migrations that used to take weeks.

The strategic case for capturing first

Migration failure is rarely "the new template is wrong." It's "we forgot the consent vendor" or "the sitemap URL structure changed silently" or "the GA4 property got swapped mid-migration and the data splits in Looker." Each of those is a capture-layer problem that a blank-template start can't catch. Capturing the old site first turns migration from a rebuild into a transformation.

Related reading

• Competitor Contrast, adjacent page-signal extractor
• WordPress + WooCommerce Audit, the audit to run before picking a migration target
• Claude MD Generator, the post-migration project-memory generator

Fact-check notes and sources

• Eleventy, Hugo, Astro, Gatsby, Next.js, Jekyll, Nuxt, SvelteKit official documentation for starter-project file conventions.
• IAB Transparency and Consent Framework (TCF) documentation for consent vendor detection.
• GDPR Art. 6 and CCPA §1798.140 for the consent-continuity legal reasoning.

This post is informational, not migration-consulting or legal advice. Mentions of third-party frameworks, consent vendors, and analytics platforms are nominative fair use. No affiliation is implied. Always verify the migrated site against the original on staging before cutting over production DNS.