Blog / Technical Guides

Lovable Site Shows 404 When You Refresh a Page: The Fix (Netlify, Vercel)

By Keyona Meeks, Founder, ReRev Labs · Oct 31, 2026 · 6 min read

The short answer: A Lovable site is a single-page app. It has one real page, index.html, and your other pages exist only in the browser. When you refresh /about, the host looks for a file at that address, finds none and returns a 404. The fix is a rule that sends every unknown address to index.html. On Netlify, add a _redirects file to your public folder. On Vercel, add a vercel.json file. Redeploy and test.

By the end of this post, you'll be able to:

  • Explain why a page loads when you click to it but fails when you refresh it.
  • Add the right rule for Netlify or for Vercel, and put it in the right place.
  • Test the fix, and know what to check if the 404 stays.

You send a link to your pricing page. The person clicks it and sees "Page not found." You open it yourself and it works, because you got there by clicking from the home page. Refresh and you see the same 404.

Nothing is wrong with your page. The host does not know that /pricing is a page. This post shows the one rule that tells it.

Why does a Lovable site show 404 on refresh?

When you click a link inside the site, your browser does not ask the host for a new page. The app already loaded, and it swaps the content and changes the address. When you refresh, or open a link someone sent you, the browser asks the host for that exact address. Hosts look for a file at that path. For /pricing there is no such file, so you get a 404.

Vercel describes the cause this way: it "resolves every URL as a server-side filesystem path by default," so client-side routes never reach index.html unless a rewrite sends them there. Source: Vercel's guide to deployed projects giving a 404, checked October 30, 2026.

Lovable's own docs say the same thing for sites hosted elsewhere: "If direct URL navigation returns a 404, configure a fallback rewrite so all routes serve /index.html." Source: Lovable's page on deploying and hosting outside Lovable, checked October 30, 2026.

How do you fix the 404 on Netlify?

Add a file named _redirects with this one line:

/*  /index.html  200

It reads: for any address, serve /index.html, and report success. The number 200 is what makes it a rewrite. Netlify's docs explain that with a 200 status, the address in the visitor's browser stays the same while Netlify fetches the new location behind the scenes. They also say this rule serves index.html instead of a 404 no matter what URL the browser asks for. Source: Netlify's page on rewrites and proxies, checked October 30, 2026.

Where does the file go?

Put it in the public folder of your project. Vite, the build tool a Lovable project uses, copies that folder to the root of the build output as is. Vite's docs say: "Assets in this directory will be served at root path / during dev, and copied to the root of the dist directory as-is." Source: Vite's static asset handling guide, checked October 30, 2026.

The file name must be exactly _redirects. No .txt, no .md.

If you would rather use a config file, Netlify's page shows the same rule for netlify.toml with these keys:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

Use one or the other. You do not need both.

One more thing from that page: Netlify does not let this rule shadow a file that exists. If a real file sits at an address, Netlify serves that file. That is what you want. It means your images, scripts and robots.txt keep working.

How do you fix the 404 on Vercel?

Add a file named vercel.json in the root of your project, next to package.json, with this content:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

That is the example in Vercel's own guide, linked above. It sends every address to index.html.

How do you ask Lovable to add the file?

You can edit the files yourself in your GitHub repository, or ask Lovable to do it. Here is a prompt you can adapt for Netlify:

Add a file at public/_redirects. The file must contain exactly this one line:
/*  /index.html  200
Do not change anything else.

For Vercel:

Add a file called vercel.json in the project root with exactly this content:
{ "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }] }
Do not change anything else.

Then check the file yourself before you deploy. Open it and confirm it says what you asked for, in the place you asked for.

How do you test that it worked?

  1. Redeploy the site. A new file does nothing until the host builds and publishes again.
  2. Open a deep address such as yoursite.com/about in a new tab. It should load the page.
  3. Refresh that page. It should still load.
  4. Open an address that does not exist, such as yoursite.com/this-is-not-a-page. You should see your app's not-found page, or a blank layout, and not the host's 404.

Test on the live address, not only on the Lovable preview.

What if it still shows 404 after the fix?

Check these in order:

  • Wrong folder. On Netlify, the file must end up at the root of the build output. Putting it in public does that. Putting it in src does not.
  • Wrong name. It must be _redirects, with the leading underscore and no extension.
  • No new deploy. Open your host's deploy list and confirm a deploy ran after you added the file.
  • Wrong output folder. Lovable's docs list npm run build as the build command and dist as the output directory for most hosts. If your host publishes a different folder, the file never reaches it.
  • Wrong problem. If every page fails, including the home page, the cause may be your domain or DNS and not this rule. Read how to deploy a Lovable website to your own domain and the DNS crash course for founders.
  • Browser cache. Try a private window.

Where does an LLM fit in this?

Not here. This is a one-line config file, and a plain rule does the same thing every time. An AI tool can help you write the file or find it in your repo, and then you check the result by testing the live site.

Where this has limits

  • I did not test this on a live Netlify or Vercel site. The file contents come from Netlify's and Vercel's own docs, linked above. Test on your own site.
  • Missing pages now return success. The rule sends every unknown address to index.html with a 200 status, so the host reports success for addresses that do not exist. Your app can show a not-found message, but the server does not return a 404 status for it. That is fine for many small sites. If it matters to you, a build that creates a real HTML file for each page is a different setup. Making your Lovable website AI crawler friendly covers one way to get static HTML pages out of a Netlify build.
  • Other hosts differ. Lovable's docs name a _redirects file for Netlify and Cloudflare and a vercel.json file for Vercel. They do not cover other hosts. Check your host's docs for a single-page app rule.
  • Lovable's own publishing was not tested here. The Lovable page I read describes this fix under hosting outside Lovable.
  • Menus change. I do not describe your host's dashboard. If you cannot find the deploy list, use your host's help pages.

If you are moving pieces of a business onto your own accounts and want a hand, you can apply for the free rebuild on /letstalk. Bring a list of the tools you pay for and which one you would replace first. Do not send passwords or login details.

Frequently asked questions

Why does my Lovable site show 404 only when I refresh?

Clicking a link inside the site changes the page in your browser without asking the host for it. Refreshing asks the host for that address, and the host has no file there. A rewrite rule sends the request to index.html, where your app takes over.

Where do I put the _redirects file?

In the public folder of your project. Vite copies that folder to the root of the build output as is, and Netlify reads _redirects from there.

Do I need both _redirects and netlify.toml?

No. Netlify's docs show the rule both ways. Use one.

Does the same fix work on Cloudflare Pages?

Lovable's docs name a _redirects file for Netlify and Cloudflare. I did not test Cloudflare Pages, so check Cloudflare's docs for the exact rule.

Will this change how Google sees my site?

It changes what your server says for addresses that do not exist: it reports success instead of a 404. I have no data on how this affects ranking, so I will not promise either way. A separate fix, prerendering pages to real HTML, changes what search engines can read.

My home page works but inner pages fail. Is it my domain?

Probably not. If the home page loads and inner pages fail on refresh, it points to the missing rewrite. If nothing loads, check your domain and DNS first.