Why I Built Site Migration Capture. A Consent Banner I Forgot Cost Me a Client

I owe this tool to a client I lost.

The migration

An SMB client hired me to move their content-heavy site off WordPress in early 2025. They were on WP-Engine on a mid-tier plan paying about 500 dollars a month. The site was 300-ish posts, a dozen landing pages, a contact form, and a newsletter signup. Classic "we don't really need WordPress anymore, we just need a static site with a good editing story."

I quoted them Eleventy, markdown, and Netlify. Ten-times cheaper to host, faster to render, easier to maintain. They agreed. I did the migration over two weekends. Content imported cleanly. Redirects mapped 1:1. Sitemap matched. Meta descriptions carried over. I did the DNS cutover on a Sunday night and went to bed pleased with myself.

The thing I missed

Their old WP site had a Cookiebot banner. Not a fancy setup, just the default. The WP plugin injected the Cookiebot script on every page, captured consent, and wrote it back to the user's browser. The setup worked. The client's legal review had signed off on it three years earlier.

My new Eleventy site didn't have Cookiebot. I forgot about it. The client forgot about it. Their legal counsel forgot about it. We launched.

Two weeks later a data-protection complaint arrived. A UK visitor had noticed tracking pixels firing without a consent prompt and filed with the ICO (UK's GDPR enforcement body). Nothing catastrophic happened — the complaint was resolved with a corrective action, no fine — but the client's internal compliance team decided that was it. They didn't want to work with a consultant who'd missed something that basic.

I lost the retainer. About 18 months of work pipeline, gone.

Why the tool

The mistake was entirely preventable. The old site WAS shipping Cookiebot. The signal was right there in the HTML of every page. If I'd had a capture step in my migration workflow that spit out a manifest saying "this site runs Cookiebot, you need to replicate it on the target," I'd have seen the line, copied the script tag, and the client would still be a client.

I built Site Migration Capture so the next consultant running the next migration doesn't lose the next client the same way I did.

What the tool captures

Twelve categories, all from publicly-served HTML. No login, no admin access needed.

1. Source identity: title, meta description, canonical, lang, H1, first 20 H2s. For sanity-checking the migrated site renders the same metadata.
2. Platform fingerprint: which CMS, which ecommerce platform, which Jamstack generator. So the import path is clear.
3. Active theme or template signature when detectable.
4. Aux files: robots.txt, ai.txt, sitemap.xml, llms.txt, manifest.json, wp-json, RSS feed. Each one has to either carry over to the new site or get an explicit decision not to carry over.
5. Consent vendor detection: Cookiebot, OneTrust, CookieYes, Complianz, Borlabs, Iubenda, Termly, Cookie Script, Osano. The one I missed.
6. Tracking stack: GTM, GA4, Meta Pixel, Hotjar, Clarity, AdSense, Google Ads, Segment, Mixpanel, Amplitude. Each has a property ID that must match on the new site or analytics continuity breaks.
7. Link graph snapshot from the homepage. Internal and external links with anchor text. Lets you rebuild navigation and spot orphans.
8. JSON-LD schema blocks count and location.
9. Web fonts loaded from Google Fonts.
10. Framework recommendation scored against all the signals. Nine target generators ranked by fit.
11. Framework visualizer: horizontal bar chart comparing fit score, perf gain, build speed, learning curve, and content-modeling across the top candidates.
12. Spawn prompt for the target generator. Includes the full manifest as JSON, so the new starter project boots functionally equivalent to the old site instead of starting from a blank template.

How I'd run it now

If I were doing the same migration today, step one would be /tools/site-migration-capture/?url=client-site.com&autorun=1. I'd read the manifest. I'd see Cookiebot listed under "privacy_and_consent." I'd add it to my migration checklist. I'd copy the original script tag into the target Eleventy base layout. Launch day, the banner would be there. No complaint, no lost client.

Total time cost of running the capture: under a minute. Total time cost of not running it: 18 months of retainer.

What else is in the capture that I wish I'd had

Beyond the consent vendor, here's what the tool catches that typical migration workflows miss:

• Analytics property IDs. Specifically the GA4 G-XXXXXXXXXX, the GTM GTM-XXXXXX, the Meta Pixel ID. Any one of these swapped silently mid-migration and you split analytics data across two properties in Looker for months before someone notices.
• Meta Pixel specifically. Facebook/Meta holds custom-audience retargeting pools against the Pixel ID. A new site with a new Pixel ID loses access to existing audiences.
• Multi-language signals. If the source site has hreflang, the target better carry it over or international rankings collapse.
• JSON-LD schema blocks. Article, Product, LocalBusiness, Person. Losing these during migration is a silent SEO regression that only shows up in Search Console two months later.
• Link graph shape. If the homepage linked to 40 internal pages and the new homepage links to 8, you've silently restructured the whole PageRank flow.

Each of those is a capturable signal. The tool captures all of them.

What the tool won't catch (and I won't pretend it will)

Anything behind login. Anything rendered server-side that leaves no wire trace. Custom plugins exposing only admin UI. Database state. Hosting-tier config (Redis, Varnish, reverse-proxy rules). Search indexes. Staff accounts. CDN rules. Payment processor integrations visible only as iframes.

For those, the capture is a starting point, not a finished migration plan. The spawn prompt explicitly asks the model to call out what needs manual re-implementation.

If you're doing a migration right now

Run the capture first. Read the manifest. Print it. Check each item off as you rebuild. Don't skip the consent banner. Don't skip the tracking IDs. Don't let the domain-cutover day be the day you discover something you forgot.

That's why this tool exists.

Related reading

• Site Migration Capture — the tool
• Consent Vendor Selection — which consent vendor to pick on the new site
• WordPress + WooCommerce Audit — audit the WP source before migration
• Platform Audit — audit the source if it's Shopify, Squarespace, Wix, Webflow, Ghost, BigCommerce

Fact-check notes and sources

• UK Information Commissioner's Office (ICO) public register for the general ePrivacy Regulation complaint pattern referenced.
• EU GDPR Art. 6 and ePrivacy Directive Art. 5(3) for the consent-requirement grounding.
• Publicly-documented migration patterns from Eleventy, Hugo, Astro, Gatsby, and Next.js official docs.
• Specific client details are intentionally omitted or generalized to respect their privacy and the NDA terms of our prior engagement.

This post is informational and autobiographical, not legal or migration-consulting advice. My experience is a single data point. Your migration and your jurisdiction's consent rules will have their own specifics. Consult privacy counsel for binding guidance on GDPR / ePrivacy / CCPA obligations.