Lovable site migration
Your Lovable site got you launched. Now get it found.
A squad audits a Lovable site, then either points you at Lovable's TanStack Start upgrade or moves the site onto a server-rendered build in your own GitHub, with the design kept and the pages written so search and AI answer engines can quote them.
Lovable can do this work inside the product. The pages, the structure, and owning the code are still yours. The xSquads app is Mac now, Windows waitlist open.
What people run into
Built on Lovable and not showing up in Google or ChatGPT? Here's why, and how we fix it.
Lovable's SEO and AI search docs say a published app returns readable HTML to search engines and to AI crawlers, and that ranking still depends on content, metadata, structure, and links. The notes below are the gaps a migration, or Lovable's own upgrade, can actually close. Each one has a check you can run before you write to us.
Hard to rank after months of work
“i spent 2-3months building my website and i just found it its hard to rank on AI and SEO”
Lovable says the starting metadata on a new project is generic, that a sitemap is not always created (a robots.txt file is), and that their review looks for duplicate titles, placeholder text, weak descriptions, and canonical URLs that point at the homepage. Passing those checks does not guarantee a ranking. Content and links are still the owner's job.
Check it yourself
Open three pages. Compare the browser tab titles, and search the page source for name="description". Then open /sitemap.xml and /robots.txt. If every page shares one title or the sitemap is missing, that is the gap Lovable's own checklist names.
What the squad does
Audits the content and the page structure, checks titles, descriptions, and the sitemap against that checklist, and writes answer-style pages an AI tool can quote. No promise of a first-place ranking.
Empty HTML, only on projects from before 13 May 2026
“a crawler gets an almost empty HTML file”
r/lovable, on moving an older project
Lovable's upgrade guide says an older React and Vite app sends the browser a mostly empty page, and the browser builds the content with JavaScript. On Lovable hosting, verified crawlers (Google, Bing, social preview bots, and the crawlers for ChatGPT, Perplexity, Claude, and Gemini) get a pre-rendered copy. Unverified bots and a normal View Source see the shell. Content that loads late may be missing from that pre-render. Projects created from 13 May 2026, and new Enterprise projects from 22 June 2026, use TanStack Start: every request gets the full page. Lovable can upgrade an older project in place. The upgrade uses credits, and the live site stays on the old version until you publish again.
Check it yourself
View Source. If your sentences are not in the HTML, you are looking at the older shell, not at proof that Google sees nothing. Ask Lovable “What stack is this project on?” To see the pre-render, use URL Inspection in Google Search Console, which is what Lovable recommends.
What the squad does
Names both options and does not pick for you in silence. One is Lovable's own TanStack Start upgrade, which keeps the project where it is. The other is a move to a server-rendered build you own, so every request gets the page, not only an allowlist of crawlers.
Headings, links, schema, and code that still sits in Lovable
Lovable's review flags a missing or generic H1, heading levels that skip, link text that does not say where it goes, and structured data that does not match the page. Separately, the GitHub sync docs say the project code is stored inside Lovable until you connect a repository you own. A sync or a codebase download (paid plans) is how you get that copy.
Check it yourself
On one page, count the H1s, see whether a heading skips a level, and read three links with the surrounding sentence hidden. In Project settings, Git, see whether a repository in your account is connected.
What the squad does
Maps the site, fixes the heading hierarchy, the internal links, and the structured data, and lands the code in your GitHub repository.
Stuck at the last stretch
“Built an app with AI and it's stuck at 80%?”
A public post, 29 October 2026, tagged Lovable. The post is someone offering a fix, not a count of how often this happens. The list under the question is bug fixes, Supabase auth and database, SEO, and deployment.
The last stretch is usually a short list: publish fails, sign-in or the database is unfinished, and the SEO items above are still open. We do not turn one post into a failure rate.
Check it yourself
Write down what still fails when you try to publish: deploy, sign-in, and the SEO checklist from the first card. That list is the scope.
What the squad does
Works from that scoped list: deploy, auth, and SEO. A human reviews every change before it ships.
The backend is still on Lovable Cloud
“And I can work on the backend?”
Yoav Levavi, 30 October 2026. The reply says that with GitHub synced you can edit the code, that your own Supabase is yours to manage, and that a Lovable Cloud backend would be migrated first: schema, data, auth, and storage.
Lovable's guide to hosting outside Lovable says the same split. Git sync copies the code, including migration files, and does not copy the rows in the database or the files in storage. Those are exported and restored on a Supabase project you own.
Check it yourself
See whether the database is Lovable Cloud or a Supabase project in your own dashboard. The Git repository will not contain the rows either way.
What the squad does
Moves the code to your GitHub and, when the backend is Lovable Cloud, the database to your own Supabase, so you own both.
How a migration runs
Audit, then upgrade in Lovable or move to a build you own.
A squad of specialised agents does the audit, the plan, and the migration, and keeps the pages healthy for search and for AI answer engines after. A person reviews the work before it ships. This sits alongside the other services and, when the rebuild should be Next.js, the Next.js work. We do not publish a price or a timeline.
Step 1
Audit
Read the live pages against Lovable's own SEO checklist: titles, descriptions, canonicals, sitemap, robots.txt, headings, internal links, and structured data. View Source tells us whether ordinary requests already contain the copy.
Step 2
Choose a path
Stay in Lovable and upgrade an older project to TanStack Start, or move to a server-rendered build you own. We say which one fits. You decide.
Step 3
Keep the design
If you move, the rebuild keeps the design people already know. Pages whose addresses change get a 301 redirect. The new site ships a sitemap and structured data that matches the visible page.
Step 4
Put it in your accounts
The code lands in a GitHub repository you own. If the backend is Lovable Cloud, the schema, data, auth, and storage move to a Supabase project you own. A person reviews every change before it ships.
Step 5
Launch
After the site is live, we submit the sitemap in Google Search Console. After that, the squad keeps titles, answer-style pages, and internal links in shape. No ranking is promised.
FAQ
Questions about a Lovable site migration
Can a Lovable site rank in Google or ChatGPT?
Yes. Lovable's documentation says published apps return readable HTML to search engines and AI crawlers, and that a Lovable app can rank like other modern web apps. Ranking still depends on the pages: titles, descriptions, structure, content, and links from other sites. This page does not promise a position.
Are all Lovable sites blank to crawlers?
No. Projects created from 13 May 2026, and new Enterprise projects from 22 June 2026, use TanStack Start and send full HTML on every request. Older React and Vite projects send a mostly empty page to ordinary requests, and Lovable pre-renders them for verified crawlers. Lovable can upgrade an older project. View Source is how you tell which one you have.
Do I have to leave Lovable?
No. If the only gap is the older stack, Lovable's TanStack Start upgrade is the path that keeps you in the project. A move is for when you also want the code in your GitHub and the database on a Supabase project you control.
What happens to the design and the old URLs?
The design stays. When a page's address changes, we add a 301 redirect from the old URL to the new one, and we submit the new sitemap in Google Search Console. We do not publish a timeline for that work.
Who owns the code and the data?
You do, once the move is done. The code goes to a GitHub repository in your account. Database rows are exported and restored on your own Supabase project. Lovable's repository sync does not include those rows, so the export is a separate step.
What does this cost?
We do not publish a price. Send the site URL and what is not working, and we will reply about the enquiry.
Send the URL.
We will tell you whether to upgrade in Lovable or move the site, and what the first fix list is.