← Back to Blog

Why I Built Site Migration Gen. The Rebuild That Lost a Client Their Brand, Their Rankings, and a Quarter of Their Traffic

Why I Built Site Migration Gen. The Rebuild That Lost a Client Their Brand, Their Rankings, and a Quarter of Their Traffic

The Site Migration Capture tool came out of one botched migration. Site Migration Gen came out of the next one, where I made a different mistake on a bigger client.

The setup

A landscaping company in the Pacific Northwest hired me late in 2025 to rebuild their site. Existing site was a 9-year-old WordPress install on a shared host, locked into a paid theme that had not been updated in three years, plugin sprawl that had grown organically through three different agency relationships. The site loaded slowly, looked dated, and the contact form had stopped emailing the owner two months earlier without anyone noticing.

The brief was reasonable. Same content, same brand, faster, cleaner, easier for the front-desk person to update a single page when a service changed. They were paying their old hosting and plugin licenses about $180 a month and wanted that down to under $20.

I quoted them an Eleventy + Netlify rebuild. Two weekends of work. They agreed.

The shortcut I took

This was the period where I had stopped writing migration prompts by hand and started leaning on Claude to do most of the rebuild. The workflow I had settled into was:

  1. Browse the existing site.
  2. Take a couple of screenshots of the homepage and one interior page.
  3. Paste them into a chat with a prompt that read, more or less, "Rebuild this site as Eleventy + Netlify. Keep the structure. Make it look modern. Use a clean color palette. Output the full project."

It worked. Claude gave me a clean Eleventy starter with a homepage, an about page, a services page, a gallery, and a contact form. The visual was modern. The build was fast. I plugged in the domain and pushed the new version live the following Sunday night.

What I lost in the rebuild

I did not realize the scope of the problem until the owner called me three weeks after launch.

His Google Business Profile was suddenly showing a different phone number on map results. His top three keywords were no longer ranking on the first page. He had stopped getting form submissions from new homeowners moving into the neighborhood, which had been one of his most reliable lead sources for years. And his daughter, who handled the books, asked him why the new site spelled the company name slightly differently than the old one.

That last one stopped me cold. I went and looked.

The old site had spelled it "Mountain View Landscape & Hardscape, LLC" in the page title, in the H1, in the footer, in every JSON-LD block, and in the schema markup tying the business to the Google Business Profile.

The new site I had built spelled it "Mountain View Landscaping". Claude had reasonably-but-incorrectly inferred a "cleaner" name from context. I had not caught it because the screenshots I gave were of the visual hero, where the logo was a graphic. The structured-data text was different.

I went through the rest of the new site. Things I had silently lost:

  • The exact business name in JSON-LD LocalBusiness schema.
  • The phone number had been auto-formatted in a way that broke the click-to-call link on mobile and dropped the area code from the schema.
  • The ServiceArea schema listing 14 specific cities the company served. The new site had a "Serving the Pacific Northwest" headline and no machine-readable service area.
  • About 60 percent of the original text on each service page. Claude had summarized rather than ported. Pages that had ranked for "paver patio installation Beaverton" no longer contained either of those phrase fragments.
  • The original 2014 founding date, which had been visible in JSON-LD foundingDate. New site had no foundingDate. (Owner cared about this. He was proud of the milestone.)
  • 11 customer testimonials with Review schema. The new site had a single rotating testimonial carousel with no schema.
  • Internal link graph. The old homepage linked to 18 interior pages. The new homepage linked to 4. Search engines saw a sudden collapse in internal authority distribution.
  • A redirect map. The old site had URLs like /services/paver-installation-portland.html. The new site had /services/pavers/. I had not built the 301s.

The functional cleanup was good. The brand erosion and SEO impact was a disaster.

What it cost the client

Three months later the owner had measurable decline:

  • Organic traffic was down about 40 percent against the same period the prior year.
  • Two of the top-three keywords had dropped to page two of Google.
  • His Google Business Profile lost the verified-name match (because the schema name no longer matched), which downgraded his map-pack ranking.
  • He estimated he had lost four to six new-customer inquiries per week through that summer that the old site would have produced.

He did not blame me. He paid the invoice, kept me on for one round of fixes, and eventually moved to a different agency that promised "to do it properly this time." Total revenue impact for him over those three months, his estimate, was somewhere north of $40,000 in landscaping work he did not get to bid on.

I refunded the project fee and stopped using the screenshot-to-Claude workflow that day.

Why a generic AI prompt is not enough

Here is what I missed, expressed as a checklist of things a competent migration prompt has to enforce:

  1. Exact business name preservation. Including the legal suffix, the punctuation, and the casing. Inferred or "cleaner" versions are forbidden.
  2. Phone number, address, hours preserved verbatim with click-to-call markup intact and schema-friendly formatting (E.164 in the schema, display format in the visible text).
  3. Service-area schema preserved. Every city, every ZIP, every county the original site listed.
  4. Foundation dates and credentials preserved. Founding year, license numbers, certifications, awards. These are E-E-A-T signals to search engines and emotional anchors to the business owner.
  5. Existing JSON-LD blocks ported as a starting point. Not regenerated from scratch. The structure that was getting credit needs to keep getting credit.
  6. All visible text preserved. Summarization by an LLM is not allowed. If a page has 800 words about paver installation, the new page has the same 800 words plus structural improvements, not 200 words "expressing the same idea more cleanly."
  7. Internal link graph preserved or expanded. Never narrowed. If the old homepage linked to 18 interior pages, the new homepage links to 18 or more.
  8. Redirect map mandatory. Every old URL maps to a new URL. No exceptions. Unmapped old URLs are a signal to ship a 410, not silently 404.
  9. Reviews and testimonials preserved with their schema. A Review block dropped is a Review block stripped from search-engine context permanently.
  10. Tracking IDs and consent vendor preserved. The same lesson from the Site Migration Capture story applies here too. New pixel ID equals lost retargeting audience.
  11. Image filenames and alt text preserved. Image search rankings depend on filename slugs that have built up authority.
  12. Open Graph image URL preserved on transitional pages so social-share previews do not break the day of cutover.

A generic "rebuild this site, make it modern" prompt enforces none of those. It optimizes for visual freshness, not for continuity. The exact attributes that make a small-business site valuable to its owner are the attributes the model is trained to "improve" out of the result.

What the tool actually does

Site Migration Gen is the prompt I wish I had pasted into Claude on that landscaping rebuild. It works in three steps:

  1. You paste the URL of the existing site. The tool fetches the live page, extracts every preserveable signal listed above (business name, schema blocks, links, images, tracking, fonts, consent), and builds a manifest.
  2. You pick the target stack (Eleventy, Hugo, Astro, Next.js, plain HTML) and host (Netlify, Vercel, Cloudflare Pages, GitHub Pages).
  3. The tool generates a single rebuild prompt that includes the manifest, the target stack instructions, and an explicit preservation contract. The prompt tells the LLM in literal terms: copy this name verbatim. Port these JSON-LD blocks. Keep these URLs. Build these 301s. Carry over these tracking IDs. Do not summarize content. Do not rename anything.

You paste that prompt into Claude or ChatGPT. The output is a rebuilt project that preserves everything the old site had earned, while replacing everything the old platform had locked in.

If I had run that on the landscaping site in 2025, the business name would have stayed the same, the schema would have stayed credible, the redirects would have shipped, and the owner would still have his organic traffic.

The companion piece

If you want the technical "what it does" walkthrough rather than the origin story, that lives in Site Migration Gen — Rebuild Your Site Without Losing What Matters. The capture-step companion tool that powers the manifest is Site Migration Capture. The "why that one exists" pain story is here.

The honest summary

A clean rebuild is not a successful migration. A successful migration is the same business, the same content, the same earned reputation, on a faster and more maintainable foundation. The two outcomes look similar at the visual level and behave very differently at the search-engine, conversion-tracking, and brand-recognition level.

If you are rebuilding a site for a client right now, do not paste a screenshot into Claude with "rebuild this, make it modern" and hit run. Run Site Migration Gen first. Read the manifest. Verify the business name is exact. Verify the phone number, the service area, the schema, the tracking IDs. Then generate the prompt and paste that.

It takes an extra minute. It can save the next client from losing $40,000 of business they never knew they were going to lose.

Related reading

Fact-check notes and sources

This post is informational and autobiographical, not migration-consulting or SEO-consulting advice. Mentions of specific platforms are nominative fair use. No affiliation is implied.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026