Why does my website work in preview but not live?

Your website works inside the builder. You publish it, open your own domain and find that the form, login or another feature has stopped working.

The preview proves that the feature can work somewhere. It doesn't prove that the public version has the same code, settings and permissions.

Why does my website work in preview but not live?

The two versions may be using different setups.

Your website can work in preview but fail live because the latest changes weren't deployed, the live version is missing a connection setting or an outside service doesn't accept your domain. Your host may also lack something the feature needs.

Production is the version customers use, while preview is for checking changes. Some platforms keep their settings separate; Vercel explains its deployment environments.

Start by identifying one task that fails. “Login returns to the preview address” gives you a clearer investigation than “the live site is broken”.

What should you check before editing code?

Repeat exactly the same task in both versions.

Save the preview address, public address and steps needed to reproduce the failure. Use a private browser window so your owner login or saved browser data doesn't hide the problem.

Try the host's deployment address too, if one is available. If that works but your custom domain doesn't, focus on the domain and services that depend on its address.

Use the symptom to choose your first check.

Live-site problem	Start with
Old text or missing changes	Latest successful deployment
Page works, form doesn't	Form connection and live settings
Login returns to the preview	Allowed login return addresses
Direct page link gives 404	Hosting rules for page addresses
Blank page or missing styling	Failed files and browser errors
Only the custom domain fails	Domain assignment and permissions

Keep a screenshot, the test time and any action that triggers the problem.

A page that opens through the menu but fails on refresh usually needs a routing fix, not a general launch diagnosis.

Did your latest changes reach the live website?

A successful editor save may not update production.

Check the host's latest deployment time, its status and which version your domain serves. A failed build can leave the previous working version live.

In Lovable, later edits need to be published again; its publishing guide explains the update flow. Other builders have their own publish actions.

Compare a small visible change, such as a heading, between the editor and public site to confirm which version you're testing.

Don't keep rewriting a feature before its newest code reaches the public domain, or each test may still check an older version.

Once the correct deployment is live, repeat the failing task in a fresh tab.

Are the connections set up for the live version?

A form or login service may need settings that only exist in preview.

Ask your developer to check the live website's service connections, addresses and credentials. Environment variables are saved settings the website reads, such as the address of a service or a private sending key.

Vercel lets those settings apply to different environments. A preview setting may not apply to production. Changes can also require a new deployment before they take effect.

Check what each setting should point to. A live form shouldn't accidentally send to a test inbox or connect to demonstration data.

Some public settings become part of the website's files during the build. Changing the dashboard value later may not change the files already deployed. Vite and Next.js document this behaviour.

You don't need to memorise the variable names. Ask which setting is missing or wrong, where it is used and whether a rebuild is needed.

Private keys should stay private: never put one in browser code, where visitors can inspect it.

Does the outside service accept your domain?

A service that accepts the preview address may reject the public one.

Login providers often use a list of permitted return addresses. If your domain isn't listed, sign-in can fail or send visitors back to the wrong site. Auth0's callback guide gives one example.

Spam-protection tools and other integrations can have domain-specific settings too; check the dashboard of the service your project uses.

If your developer reports a CORS error, it means the browser isn't allowing a request to another service under that service's current rules. The fix belongs in the relevant service or connection setup, not in telling customers to disable browser security.

MDN explains these cross-site request rules. Ask for a change that allows your domain. Private data should stay protected.

If the preview is ready but the public site still fails, we can finish the launch properly. If your site is custom-coded, we'll quote the work to make production match, based on what's failing. Framer and Webflow projects fall outside our repairs, though we can talk about a rebuild. Book a free intro call with no commitment, or reach hi@aruno.studio, WhatsApp or Telegram at @mihaipostelnicu.

Can your host run the feature?

The live host must support how your website was built.

A host serving only saved HTML, CSS and image files can't run every server-side feature. For example, a contact form may need a separate sending service or a server function.

Next.js lists different deployment options. A static export doesn't provide every capability of a server-backed deployment.

Ask your developer to compare what the feature needs with what your host runs. Don't move hosting until that mismatch is confirmed.

If the main issue is that the page loads slowly, follow the mobile speed checks. If the domain shows a warning, check its secure connection first. Our website audit reviews what visitors see, such as design, speed, copy and SEO; deployment and connection problems like these are repair work.

How do you test the fix?

Finish the actual customer task from a fresh visit.

Check	What it should prove
Open the public domain privately	It works without the owner's saved session
Use an ordinary visitor account	The intended permissions work
Complete the form or login	The feature works beyond its first screen
Try a real phone	Touch and mobile behaviour work
Repeat after a fresh deployment	The fix exists in production

For a form, confirm receipt in the intended inbox. For login, confirm the destination after sign-in and which pages the visitor can access.

Don't remove access rules just to make a test pass: that changes what you're testing and can expose data.

Frequently asked questions

Does a working preview mean the code is correct? It means that version works under the preview's conditions. The public version may use different settings or services.

Can refreshing fix it? A fresh visit can reveal an old-tab problem. It won't add missing live settings or deploy code that never reached the host.

How much does a repair cost? It depends on whether the cause is a setting, deployment issue or missing feature. Ask for a specific diagnosis before accepting a rebuild quote.

How long does it take? A wrong setting can be corrected quickly once found. Changes to hosting or sending code need more testing.

Check the version and connections your customers actually use. That's where the repair needs to work.