Using Lovable with an existing website: what works and what breaks

Lovable is one of the better-known prompt-to-site AI builders, and once a team sees what it can spin up from a blank canvas the natural next question is: can I point it at the website I already have? Can I import my current site, let Lovable restyle it, add pages, fix the embarrassing bits, and carry on?

The short answer is that Lovable is not really built for that job. It is a generator, not an editor of your existing stack. There are workarounds, and they can get you a long way if what you actually want is a rebuild. But if your goal is to keep your current CMS, URLs, integrations and search rankings while making the site easier to update, Lovable is the wrong shape of tool.

What Lovable is actually designed for

Lovable's core loop is prompt in, project out. You describe what you want and it generates a fresh codebase, typically a React app built on Vite, styled with Tailwind and shadcn/ui, with Supabase wired up for anything needing a database. It deploys to its own hosting by default and can push to Vercel or Netlify. Every project starts life as a brand new repository.

That design decision matters. The product is optimised for founders prototyping an idea, small businesses without a site yet, and designers turning a concept into something clickable in an afternoon. It is less suited, and in several cases simply does not work, for teams who already have a production website on WordPress, Sanity, Contentful, Webflow, Shopify, Drupal or a bespoke stack.

Can you point Lovable at an existing website?

There is no connect-my-current-site button. You cannot paste a URL and have Lovable adopt the live site as its working copy. What you can do is one of three things.

First, prompt Lovable with a reference URL and ask it to recreate the look and feel. It will produce something visually in the ballpark, but it is a new site based on screenshots and inferred structure, not a working migration. None of your real content, metadata or integrations come across.

Second, import a Figma file. If your existing site has a current design system in Figma, Lovable can generate components that match. This is the cleanest path, because the generator works from structured inputs rather than guessing from pixels.

Third, import a GitHub repository. Lovable can clone a repo and then edit it. The caveat is heavy: its editing model is tuned for React, Vite, Tailwind and shadcn. A Next.js app may get usable edits. A WordPress theme, a Hugo site, a Rails monolith or a Shopify Liquid theme will not.

What survives any of these routes: visual layout, component shapes, static copy you paste in. What does not: your database schema, CMS content model, server-side logic, authentication, access control, redirects, structured data, analytics configuration, A/B tests, personalisation rules, and anything living in a plugin.

Four realistic workarounds for working with a live site

If you are determined to put Lovable to work alongside an existing website, these are the patterns that actually ship.

The limitations most teams hit

Framework lock-in comes first. Lovable is a React shop. A WordPress site is not just HTML; it is themes, plugins, custom post types, ACF fields, a MySQL database, a REST or GraphQL layer and dozens of hooks. You cannot prompt your way across that gap in a weekend.

Then stranded content. Your blog posts, case studies and landing pages live in your current CMS. Lovable will not reach into Sanity or WordPress and pull them out. You will export to Markdown or JSON, remodel the content types as components, and import. Expect this to be the longest phase of any migration.

SEO gets rebuilt from scratch. Slugs, canonical tags, hreflang, Open Graph defaults, JSON-LD for Article, Product, Organization, Breadcrumb and FAQ. None of this moves automatically. Your sitemap needs regenerating, and every URL needs a 301 redirect to its new equivalent. On a site with hundreds of indexed URLs that is a multi-week job in its own right.

Integrations do not carry. Your CRM forms, chat widget, analytics, checkout, search and email signup all need re-wiring. Some are script-tag drop-ins; anything server-side needs rebuilding. And design drifts: a URL-import rebuild looks like your old site at a glance and nothing like it on close inspection.

A practical migration workflow if you do commit

✓

Audit first. Inventory every URL, with traffic from Search Console, inbound links and conversion contribution. You cannot decide what to keep, consolidate or kill without this.

✓

Export content to a structured format. Markdown with frontmatter, or JSON that maps to your planned component props. Treat this as the source of truth during the rebuild, not the live site, which keeps changing.

✓

Rebuild templates before content. Prompt the templates first, then pour exported content through them. Reverse this and you get inconsistent layouts and heavy manual cleanup.

✓

Map every URL and script the redirects. Old URL, new URL, status. Those redirects go in at the edge so they fire before any JavaScript loads.

✓

Rebuild SEO primitives and validate with a rich-results test and a crawler before cutover.

✓

Run both sites in parallel. Deploy to staging, crawl it, compare against live, and only switch DNS once redirects, titles, metas, structured data and Core Web Vitals are signed off.

This is a project, not a weekend. Teams who treat it as a weekend ship broken redirects, lose rankings for three months, and spend the recovery budget they thought they had saved.

Rebuild versus editing your existing site in place

The honest comparison is not Lovable versus other builders. It is rebuild versus keep, and the answer depends on what your current site is actually worth.

If your site is young, lightly ranked, lightly integrated and already due for a redesign, a rebuild is reasonable. You trade a few weeks of migration pain for a cleaner codebase, and the ranking risk is low because you were not ranking for much yet.

If your site is five years old, ranks for hundreds of commercial terms, has a backlink profile that took years to earn, runs on a CMS your editors know and plugs into a dozen operational tools, the maths looks very different. A rebuild risks a visible drop in organic traffic for months while Google re-crawls and re-evaluates.

In that second case the real problem is usually not the stack. It is the workflow: tickets sit in a queue, agencies are slow, copy changes take days, nobody maintains the blog. That is a people-and-process problem dressed up as a technology problem. Rebuilding the stack does not solve it. Changing how you edit the stack does.

The agent-based alternative: edit the site you already have

Agentic Web Team was built for exactly that scenario. It connects to the CMS and repository you already use, whether WordPress, Sanity, Contentful, Webflow or a custom Next.js codebase, and gives you an AI team you can brief in chat. Content edits, new landing pages, code changes, image generation, SEO work. All on the site you already have, in the stack your team already knows.

The operational model is deliberately different from a prompt-to-site builder. Changes are drafted on a staging branch, not applied to production directly. Role-based permissions decide who can request what, approvals route to the right human before anything ships, and the audit log records every edit. Your repo stays yours, your content model stays yours, your URLs stay yours, your rankings stay yours.

What you get is the velocity people want from Lovable, applied to the site you already run. Instead of describe a new site and I will build it, the loop is describe the change you want to your current site and I will draft it, show you the diff, and ship it when you approve.

How to decide in a single afternoon

Write down the three things about your current website you absolutely cannot lose. Rankings for your top five commercial terms. A specific CRM integration. A gated library behind authentication. Be concrete.

Then write down the three things blocking you from updating the site as fast as you want. If those blockers are visual, the design feels dated, the information architecture is wrong, then a rebuild is on the table and Lovable is a credible way to run one. If the blockers are operational, editors cannot publish without a developer and every change needs a sprint, then the problem is workflow, not stack.

Two weeks of parallel trials will tell you more than two months of planning. For most established sites with real rankings, real integrations and real editor habits, the honest recommendation is: keep the site, change how you edit it. Lovable is a brilliant generator. For an existing website, a generator is rarely what you need.

Frequently asked questions

Can Lovable import my existing website?

Not in the sense of adopting your live site as its working copy. Lovable can take a reference URL, a Figma file or a GitHub repository as a starting point and generate a new project that resembles your current site. Your real content, CMS schema, integrations, redirects and SEO metadata do not come across automatically, and have to be rebuilt.

Does Lovable work with WordPress, Sanity, Contentful or Webflow?

No. Lovable generates React and Vite projects styled with Tailwind and shadcn, typically with Supabase as the database. It does not edit WordPress themes, Sanity Studio schemas, Contentful models or Webflow projects. If you are on one of those platforms and want AI-assisted editing without migrating, an agent that connects to your existing CMS is a better fit.

Will I lose my SEO rankings if I rebuild my site in Lovable?

You risk it. A rebuild resets your URL structure, metadata, structured data and sitemap. Without mapping every old URL to a new one with 301 redirects and carefully rebuilding schema and canonical tags, you will see ranking drops while Google re-crawls. Established sites with meaningful organic traffic should treat a Lovable migration as a full replatform project.

What is the alternative to rebuilding an existing site in Lovable?

Edit the site you already have using an agent that connects to your current CMS and repository. Agentic Web Team does this for WordPress, Sanity, Contentful, Webflow and custom codebases. Changes are drafted on a staging branch, routed through approvals, and shipped through your existing deployment pipeline, so your URLs, rankings and integrations stay intact.

When does it make sense to use Lovable for an existing site?

When a redesign or replatform was already on the roadmap, when the current site is young and lightly ranked, or when you want to spin up a separate microsite or campaign page on a subdomain without touching the main stack. For a mature site with established rankings and operational integrations, Lovable is usually the wrong shape of tool.

Can Lovable edit a live site directly?

Lovable edits the project it generated, which deploys to its own hosting or to Vercel or Netlify. It does not reach into a separate live site that it did not generate. If you need an AI that edits your current production site through staging and approvals, you need an agent built for that workflow rather than a prompt-to-site generator.