For Lovable
This procedure is for Lovable.
Read the base symptom guideLovable shows a blank page after publishing
Your Lovable preview renders, while the link copied from the publish dialog gives you an empty or inaccessible page.
Begin inside the Lovable project that produced the link. The editor and the published website are separate views of your work. A later edit is not automatically the version visitors receive. This procedure adds the publish snapshot and audience checks to the browser evidence, so you can avoid diagnosing an unpublished repair as a fresh failure.
01 / Procedure
The two-minute check.
- Inspect the publishing destination.
Open the project’s Publish dialog and copy its website URL. Open that address in a separate tab. Compare it with the link you were testing; a project name change is not evidence that the published address changed.
- Check for unpublished changes.
Read the publish dialog before taking another action. If your intended repair is still unpublished, review it and use Publish changes when ready to release that snapshot. Wait for publishing to finish, then revisit the copied website URL.
- Check who can view the website.
Inspect the audience setting in the publish dialog. Compare that intended audience with the account used in the separate tab. Keep restricted apps restricted; an access gate should not be diagnosed as an empty application render.
- Capture the live failure after those checks.
On the actual website, use Chrome Inspect and open Console. Reload and record the earliest startup failure and its file location. Then open Network, reload again and inspect any failed script response. Include which published URL produced this evidence.
02 / Evidence
Read the result.
WORKSThe reviewed Lovable snapshot renders for a visitor in its intended audience.
BROKENThat published snapshot still fails to render after access and URL checks.
03 / Repair
Causes and fixes.
Ranked in the order to investigate, not by claimed frequency.
- The fix exists only in the editor.
Publish the reviewed changes and test the resulting public snapshot. Keep a short note of what changed so you can tell whether the page you opened contains that repair.
- The test visitor is outside the website audience.
Test with an account that belongs to the intended audience or correct an accidentally chosen access setting. Do not make a private project public simply to remove the gate.
- The deployed app fails during startup.
Use the first live console failure to request a targeted change. Include the failed script URL if present. After the change, repeat both the publish step and the live browser check; another preview screenshot is insufficient.
04 / Limits
Edge cases.
- A custom domain and the published Lovable address should be compared separately. One working while the other fails narrows the investigation to delivery or domain configuration.
- Publishing changes may affect access settings as well as code. Review what the dialog will apply before using it on an app with private users.
When to stop and hand it over
Stop when the intended snapshot is published for the intended audience but the first live error still cannot be explained. Share the website link, the time of publishing and a redacted console excerpt. Leave credentials and private response bodies out of the report.
05 / Questions
Before the next attempt.
Why does changing the preview not repair the live website?
Lovable publishes a snapshot. Later project changes need another publish before visitors receive them.
Should I switch to public access as a debugging step?
Only if public access is what the product should have. Test the configured audience without exposing a private app.