Lovable Redirects in WordPress: Keep Old URLs

What a redirect has to do here

A Lovable site and a WordPress site are two different systems serving the same addresses. Lovable resolves /pricing through its router. WordPress resolves /pricing through a page with the slug pricing. If the slug matches, nothing else is needed.

Problems start where the two disagree. WordPress may create /pricing-2 because a page with that slug already exists. A nested Lovable route like /services/seo becomes a top-level page unless you set a parent. A blog array that became real posts may now live under /blog/post-name instead of /posts/post-name.

For each mismatch you want a 301 redirect, the permanent kind. A 301 tells browsers and search engines the address moved for good, and it passes the old URL's ranking signals to the new one. A 302 says temporary and does not.

• Same path, same page — no redirect needed, just a matching slug.
• Changed path — 301 from the old path to the new one.
• Page no longer exists — 301 to the closest relevant page, not blindly to the home page.
• External links you control — update them too; redirects are a safety net, not a fix.

Build the list of old URLs first

You cannot redirect what you have not written down. Get the full list of Lovable routes before you touch WordPress. The code tells you exactly, with no guessing.

Where to look depends on when the app was built. Apps created from 13 May 2026 use TanStack Start with file-based routes in src/routes. Each file is a route, so the folder tree is the URL tree. Older React + Vite apps declare routes in src/App.tsx, usually as a list of <Route path="..."> entries pointing at components in src/pages.

1. Export the code so you can read it. GitHub sync works on every plan; the ZIP download needs a paid plan. See how to export Lovable code.
2. Open src/routes or src/App.tsx and copy every path into a spreadsheet, one row per URL.
3. Add the live URLs you know about from analytics, Search Console or your own link checks, in case a path is reachable but not obvious in the code.
4. Open public/_redirects if the project has one and add those rules as well; they are already part of your URL surface.
5. Mark each row with the WordPress slug you expect after conversion, and leave a column for the result after you test.

Match slugs instead of redirecting

The cleanest redirect is the one you never need. If the WordPress page slug equals the old Lovable path, the URL simply keeps working.

When you convert with our tool, each Lovable page route becomes a WordPress page and the route path is used as the slug. The pages are created when you activate the theme, and the front page is set for you. In most projects the majority of URLs line up without any further work.

Check them anyway. Open Pages in the admin and compare the slug column against your spreadsheet. Fix a slug by editing the page and changing the URL field in the sidebar. If a stray draft or an auto-created page is holding the slug you want, rename or delete it first, then set the slug on the right page.

Nested routes need one extra move. Set the parent page in the page sidebar so /services/seo resolves under /services. Confirm that your permalink structure is the one you want under Settings → Permalinks, and do not change it again after launch.

Redirects the converter carries over

Lovable projects can ship a public/_redirects file. It is a plain text file, one rule per line: the old path, whitespace, the new path, and usually a status code. Static hosts read it at deploy time.

Our converter reads that file and carries the rules into the generated WordPress theme, so the rules you already rely on survive the move. You can see the full list of what travels and what does not on the supported features page.

Two limits are worth naming. Rules written for a host-specific syntax, such as proxying or splat rewrites to an API, do not have a WordPress equivalent and need a developer. And redirects are only as good as the file; if the project never had one, there is nothing to carry over and you build the list by hand as described above.

Adding redirects in WordPress

WordPress has no redirect screen in core. You add rules in one of three places, and the right one depends on who maintains the site.

A redirect plugin is the usual answer for site owners. Yoast, Rank Math and SEOPress all handle redirects in their paid or free tiers depending on the plugin, and there are dedicated redirect plugins in the WordPress plugin directory. You paste the old path and the new path, pick 301, and save. Non-developers can keep maintaining the list later.

Server-level rules are faster and survive plugin changes. On Apache they go in .htaccess; on Nginx they go in the server config, which usually means asking your host. Keep them above the WordPress rewrite block so they fire first.

Whichever you choose, use one place only. Redirects defined in two systems produce chains and loops that are painful to debug months later.

• Plugin — easiest to edit, visible in the admin, costs a little performance.
• .htaccess or Nginx — fastest, no admin UI, needs server access.
• Theme or custom code — only if a developer owns the site long term.

Test before you let search engines in

Keep the staging site out of the index while you work. Settings → Reading has a checkbox named "Discourage search engines from indexing this site". Leave it checked during the build and uncheck it the moment you go live, or the new site will not be indexed at all.

Then walk your spreadsheet. Open every old URL on the new site and record what happened. A correct result is one hop to a 200 page, not a chain and not a 404.

After launch, watch for what the list missed. Your server or analytics will show 404s for paths real people requested. Add a redirect for each one that matters, and leave genuinely dead paths as 404s rather than pointing everything at the home page.

1. Check the obvious paths: home page, every top-level route, every nested route.
2. Check trailing slashes: /pricing and /pricing/ should both resolve, with at most one redirect between them.
3. Check case: old links may be mixed case; decide whether you redirect them or let them 404.
4. Confirm 301, not 302, with your browser's network tab or any HTTP header checker.
5. Re-test after launch on the live domain, because staging paths and DNS can mask a mistake.

What redirects cannot rescue

A redirect only moves a visitor to an address. It does not recreate content that the move left behind. Be honest about that before you publish.

Some Lovable features never arrive in WordPress: Supabase data, authentication, dashboards, API calls, canvas, Lottie, iframes and custom React state or event handlers. If a URL pointed at an app screen behind a login, there is no WordPress page to redirect it to. Our converter reports those screens instead of converting them. Decide whether to keep that part running on Lovable at a subdomain, rebuild it, or retire the URL.

Per-page meta is a separate job. Apps built on TanStack Start expose a head() per route, and the converter writes those titles and descriptions into Yoast, Rank Math or SEOPress. Older React + Vite apps keep their per-page meta and Open Graph tags outside what we can read, so you set those in your SEO plugin after import. There is more detail in our guide on Lovable and SEO.

If you are doing the whole move now rather than just the URLs, follow the migration launch checklist so redirects land in the right order alongside DNS and indexing.

FAQ

Do I need redirects if I convert my Lovable site to WordPress?

Often only for a few URLs. The converter uses each Lovable route path as the WordPress page slug, so most addresses keep working unchanged. You need 301 redirects where a slug changed, where a nested route lost its parent, or where a page no longer exists.

Does the IQDesk converter import my public/_redirects file?

Yes. If the Lovable project contains a public/_redirects file, the converter carries those rules into the generated WordPress theme. Host-specific syntax such as proxy or rewrite rules to an API has no WordPress equivalent and needs a developer.

Should I use 301 or 302 redirects after moving from Lovable?

Use 301 for a permanent move, which is what a migration is. A 301 tells search engines the address changed for good and passes the old URL's ranking signals to the new one. A 302 means temporary and does not pass those signals the same way.

Where do I add redirects in WordPress?

WordPress core has no redirect screen, so you use a redirect plugin, your SEO plugin's redirect feature, or server rules in .htaccess or the Nginx config. Plugins are easiest to maintain from the admin. Pick one place and keep every rule there to avoid chains and loops.

How do I stop my new WordPress site being indexed while I test redirects?

Go to Settings then Reading and tick the checkbox named Discourage search engines from indexing this site. Leave it on while you build and test. Untick it before launch, otherwise the finished site will not be indexed.

Keep reading