Moving an AI-built site off the builder’s cloud to Vercel or Railway is, reassuringly, a deployment change rather than a rebuild. Your site is code, so the job is to get that code into a Git repository, connect the repo to the new host, set the build command and environment variables, and deploy, then point your domain at it. Because the URLs stay the same, SEO is unaffected. WPBuildAI sets up the repo and deployment so you own the code and the hosting, with URLs preserved.
Managed backends move underneath you, which is part of the case for controlling the deployment: Supabase logged Envoy becoming the default self-hosted API gateway on 17 July 2026 as a breaking change, following a breaking Postgres 15 to 17 move in May.
The site is code, so the move is portable
The reason this move is easy, unlike migrating off WordPress, is that a modern AI-built site is just code: files, components, assets, and a build configuration, not a database-driven application tied to one platform. That portability is the whole point. The 2024 Web Almanac documents how the web has shifted toward these build-and-deploy front ends, which are designed to run anywhere that can build the repo. So moving hosts does not touch your content, your URLs, or your design; it only changes where the same code is built and served. This is the same ownership principle as keeping the code in your own GitHub repo: once the site is code you control, the hosting underneath it is a swappable layer. Contrast this with a CMS migration, which moves content between fundamentally different systems; a host move is far simpler because nothing about the site itself changes.
Vercel or Railway: matching the host
The two hosts suit different shapes of site, so match the host to what your site needs. Vercel is built for front-end and serverless applications, static sites, frameworks like Next.js, and sites whose dynamic needs are handled by serverless functions; it excels when there is no long-running backend. Railway suits applications that need a persistent backend or a database, a site with a running server process, a database it queries, or background jobs. The question to ask is whether your AI-built site has a server component or a database. If it is essentially a fast front end with maybe some serverless calls, Vercel fits naturally. If it has a real backend, Railway (or a similar platform) handles the persistent process Vercel is not designed for. Either way the deployment mechanics are similar, connect the repo, configure the build, deploy, but choosing the host that matches your architecture avoids fighting the platform later.
The deployment steps
The move follows a consistent sequence on either host:
- Export the code to a Git repository, so the site lives in a repo you control (GitHub, GitLab, or similar).
- Connect the repo to Vercel or Railway, authorising the platform to build from it.
- Set the build command and output settings the framework needs, so the platform builds the site correctly.
- Add environment variables, API keys, database URLs, and any secrets the site uses at build or run time.
- Deploy and test on the platform’s preview URL, confirming the site builds and works before touching your domain.
- Point your domain at the new host and verify.
The order matters: deploy and test on the platform’s own URL first, so you confirm everything works before pointing your live domain, which is what keeps the cutover clean.
A worked example: moving a Lovable site to Vercel
Picture a site built in an AI builder, hosted on the builder’s cloud, that you want to own on Vercel. You export the code to a GitHub repo, connect that repo to Vercel, and Vercel detects the framework and suggests the build settings. You add the environment variables the site uses, an API key or two, and deploy; Vercel builds it and gives you a preview URL where you confirm the site looks and works exactly as before. The URLs are identical because the code and its routing did not change, only where it is built and served. You then add your custom domain in Vercel, update the domain’s DNS to point at Vercel, and the site is live on hosting you own. Nothing about the content, design, or URLs changed, so search engines see the same site at the same addresses. The whole move was a deployment exercise, not a rebuild, which is exactly why it carries so little SEO risk.
Keep SEO intact: same URLs, no redirects needed
The SEO story here is unusually simple, and it is worth being precise about why. Search engines key on URLs and content. A host move changes neither, the same code serves the same pages at the same URLs, so there is nothing to redirect and no rankings to lose. This is the case Google describes in its guidance on moving a site without URL changes: when only the infrastructure changes and the URLs stay the same, the move is essentially transparent to search. This is the opposite of a CMS migration, covered in site moves with URL changes, where every URL changes and a redirect map is mandatory. So the single most important SEO decision for a host move is simply to keep your domain and URLs identical, which a code-only host change does by default. As long as you do not also restructure URLs at the same time, there is no redirect work and no ranking risk.
The one risk: downtime at cutover
If SEO is not the risk, what is? Downtime during the DNS switch, and it is manageable. When you point your domain from the old host to the new one, there is a window where DNS propagates and visitors could hit the wrong host or an error if the new one is not ready. The mitigations are standard: deploy and fully test the site on the new host’s URL before pointing the domain, so the new host is confirmed working first; lower your domain’s DNS TTL ahead of the switch so the change propagates quickly; and keep the old host live during the cutover so there is always a working target until DNS fully moves. Done this way the cutover is seamless, with no visible downtime. This is consistent with Google’s general advice to handle moves carefully and monitor afterward. The risk is operational and brief, not an SEO one, which is the reassuring shape of a host-only migration.
Why own your hosting
It is worth being clear about why you would do this at all, since the builder’s cloud often works fine to start. The reason is ownership: control over deployment, cost, scaling, and freedom from lock-in to one platform. On your own repo and host, you decide when and how to deploy, you can tune performance, and Portent’s study of site speed and conversion is a reminder that the speed you control is worth controlling. You are also not dependent on the builder’s hosting pricing, uptime, or continued existence; the builder becomes a tool you used to create the code rather than a landlord you rely on indefinitely. If your site has a backend, the considerations overlap with making a site headless and moving to Next.js. Owning the stack turns the AI builder from a platform you are tied to into a step in building a site you fully control, which is the strategic case for the move beyond any single feature.
Common mistakes moving hosts
The recurring errors are operational, since the SEO side is straightforward. Pointing the domain at the new host before deploying and testing there risks downtime or a broken live site during propagation. Forgetting to set environment variables means the build fails or the site runs without its keys and integrations. Choosing the wrong host for the architecture, Vercel for a site that needs a persistent backend, or vice versa, leads to fighting the platform. Restructuring URLs at the same time as the host move turns a zero-risk migration into one that needs a full redirect map, so keep the two changes separate. And not lowering DNS TTL beforehand makes the cutover drag. Each is avoided by deploying and testing on the new host first, configuring env vars, matching the host to the architecture, keeping URLs identical, and preparing DNS, which makes a host move the clean, low-risk change it should be.
Key points to remember
Moving an AI-built site from the builder’s cloud to Vercel or Railway is a deployment change, not a rebuild, because the site is portable code: export it to a Git repo, connect the repo to the host, set the build command and environment variables, deploy and test on the host’s URL, then point your domain. The SEO risk is essentially zero as long as the domain and URLs stay identical, since search keys on URLs and content and a host move changes neither, so keep the host move and any URL restructuring separate. The real risk is brief downtime at the DNS cutover, mitigated by testing on the new host first, lowering DNS TTL, and keeping the old host live during propagation. Choose Vercel for front-end and serverless sites, Railway for ones needing a persistent backend, and own your stack for control and no lock-in. WPBuildAI sets up the repo and deployment, so you own the code and host with URLs preserved; send your site URL for a fixed quote.
Not affiliated with Vercel, Railway, WordPress, or Lovable.