Rebuild Your SPA So AI Crawlers Can See Every Page

Tech SSG migration is the process of rebuilding a SPA or legacy site into route-level HTML that AI search systems can crawl, index, and cite. If your site returns the same HTML shell for every route, answer engines do not get a real document set. That breaks the visibility stack before content and outreach even start.

In 2026 audits at Humanswith.ai, we keep seeing the same failure pattern. Teams invest in content, but the site still behaves like one shell for crawlers. That is why Humanswith.ai offers a fixed-scope Tech SSG Migration service. We rebuild SPA and legacy sites with Astro 5 + Decap CMS so each priority URL outputs unique HTML, clean schema, and an editorial workflow your team can use. The scope is clear: $12,300, 410 hours, 3 months. For companies on Lovable, React SPA, Webflow without SSR, or legacy WordPress, this is the prerequisite for everything else to work.

Why AI Crawlers Cannot Cite What They Cannot Render

AI visibility does not start with copy. It starts with renderability.

AI crawlers fetch raw HTML. If the bot receives one shell and a client-side app loads the real content later, the page-level signals never arrive in the right place:

• unique page content
• structured data tied to the right URL
• internal linking between real documents
• headings and entity context per page
• clear relationships between service, case, team, and location pages

That is the core reason many content programs underperform. The writing can be strong. The problem is simple: the bot never receives a distinct document for the page you want cited.

In practical terms, a broken rendering model creates three business problems:

That is why this service exists as a migration offer, not as generic consulting. The goal is to produce a site structure AI crawlers can index, interpret, and cite with confidence.

Where Companies Go Wrong

The technical failure pattern is easy to spot once we inspect route output.

• teams judge the site in the browser instead of from raw HTML
• teams publish structured content before fixing route-level rendering
• teams treat migration as a design project instead of an AI search prerequisite

That sequence wastes time. The right order is different: first restore document-level crawlability, then scale content, then build third-party signal distribution.

Mint Link: The Audit That Made Migration Non-Negotiable

Mint Link is the clearest proof of when technical migration stops being optional.

At audit, Mint Link scored 37/100 on the composite AEO model. The product itself was not the main blocker. The blocker was the site architecture. Mint Link was running on a React 18 + Vite SPA built on Lovable.dev, and the route layer behaved like a single document.

The critical finding: 11 of 13 routes returned the same 3.3KB homepage HTML. For AI systems, that meant one shell standing in for the whole site. The bot could not distinguish the homepage from package pages, comparison pages, or product-specific routes. That made structured content, entity separation, and per-page schema far weaker than they looked in the browser.

This is the pattern we now look for early in discovery:

• React SPA without SSR or SSG
• Lovable or similar builders where content renders client-side
• legacy WordPress installs with brittle templates and inconsistent schema
• marketing teams trying to scale AI search visibility on top of unstable page output

Once that pattern appears, the sequence changes. We do not push content first and hope for the best. We fix the site structure first so future content and outreach have a real surface to land on.

How the Migration Works

This is a delivery service, not an abstract audit.

Use this checklist when you want to know whether migration is the next step:

1. Fetch raw HTML from 5-10 important routes.
2. Compare whether the response changes by page type.
3. Check whether schema, headings, and entities belong to the route being loaded.
4. If the site still behaves like one shell, rebuild the route layer before content scale-up.

1. Technical Audit and Migration Blueprint

We start with the current rendering model, route behavior, schema inventory, crawl output, and editorial workflow. The objective is to identify where the site collapses distinct URLs into one shell and where schema, metadata, or navigation break page-level understanding.

2. Route Rebuild in Astro 5

We move the site into Astro 5, where static generation becomes the default. Every important route outputs its own HTML document. That gives AI systems a stable URL-to-document relationship instead of a JavaScript-dependent interface.

3. Editing Workflow in Decap CMS

We pair the build with Decap CMS so the team can manage content through a git-based workflow without adding monthly CMS overhead or vendor lock-in. Performance matters. Operational continuity after launch matters just as much.

4. Schema, Sitemap, Robots, and QA

We wire the technical assets that AI and search systems depend on:

• reusable schema helpers
• sitemap generation
• robots and crawl rules
• canonical logic
• route-level metadata
• QA and launch checks

This is what turns a migration into an AI search ready platform instead of a front-end redesign.

What Changes Technically

The most important change is not visual. It is architectural.

There are also practical stack reasons this route wins.

Why Astro 5 + Decap CMS

• SSG by default: route output is crawlable immediately.
• Content collections: structured content models are easier to govern.
• Native sitemap and robots tooling: lower setup friction.
• React reuse: existing React components can be preserved where it makes sense.
• Git-based CMS: content edits stay transparent and low-cost.
• Zero vendor lock-in: the team owns the code and content model.

For larger editorial estates, we use Astro + Sanity instead. For the core migration offer in this service tier, Astro 5 + Decap CMS is the recommended default.

What Is Included in the $12,300 Scope

The offer is a fixed-scope technical migration, not an hourly mystery project.

The pricing is based on a documented scope from the Mint Link migration plan:

• 410 hours
• $30/hour
• $12,300 fixed
• 3 months

That timeline is designed to replace the pattern where technical debt keeps blocking AI search work quarter after quarter.

Where This Fits in the Full Service Model

This migration can run as a standalone engagement. In SPA and legacy-site cases, it sits inside the broader V2 offer.

That creates two common buying paths:

• Standard vertical: $21,100 for analytics, content, and outreach when the site is already technically viable
• Enterprise full-stack combo: $33,400 when the site must be migrated before the visibility program can work

The decision logic is simple:

• already on a crawlable static or SSR setup -> standard vertical is enough
• on Lovable, React SPA, Webflow without SSR, or legacy WordPress -> migration is required first

What Success Looks Like After Migration

We do not measure this service as a design refresh. We measure whether the technical layer stops blocking AI visibility.

Success looks like:

• each priority URL serves unique HTML
• structured data aligns with the page it belongs to
• crawlers can follow the site as a document set, not a JavaScript shell
• performance improves toward SaaS-grade speed
• marketing can publish and update pages without reinventing the stack each time

For Mint Link, the target path is clear: move from a 37/100 composite audit baseline to a technically viable site architecture that can support a 75+ target once the migration and V1 visibility program are in place.

FAQ

Do I need this if I already have strong content?

If your current site architecture prevents crawlers from seeing distinct page documents, then yes. Strong content on a broken rendering model is still hard to cite. This migration fixes the technical layer so content and outreach can compound instead of stall.

Why not stay on Lovable or a React SPA?

Because the issue is not aesthetics. It is crawl behavior. If the site keeps returning one shell and relying on client-side rendering, AI crawlers get a much weaker representation of the site than users do in the browser. That gap is exactly what this service removes.

When do you choose Astro + Decap CMS versus Astro + Sanity?

We recommend Astro + Decap CMS as the default for this offer because it is fast, cost-efficient, git-based, and a strong fit for content sites that do not need a heavy hosted CMS. If the site requires a larger editorial system or a more complex content operation, Astro + Sanity can be the better fit.

Can the migration run before the content and outreach program?

Yes. For SPA and legacy-site cases, that is the right sequence. We fix the technical blocker first, then move into analytics, content, and outreach on a site that AI systems can actually read.

How do you measure success after migration?

First, technically: unique HTML per route, schema integrity, crawlability, performance, and launch readiness. Then commercially: whether the site is finally capable of supporting the $21,100 visibility program and moving toward better citation outcomes in AI search.

Is this generic consulting?

No. It is a fixed-scope migration service with a defined stack, a defined timeline, and a defined outcome. The offer exists because AI visibility work fails when the site structure is wrong.

Book the Migration Audit

If your site still behaves like one shell for AI crawlers, content alone will not fix the problem. We can show you where the rendering model blocks citation, what must change, and whether your case needs the standalone migration or the full $33,400 enterprise program.

Book a 30-minute call to review the site structure before more budget goes into content that AI systems still cannot see properly.