Figma Make Works in Preview but Not After Publishing

Your Figma Make project works when you test it in preview. Buttons respond, pages appear and the interface looks ready. Then you publish it, send the link to somebody else and discover a blank page, broken navigation or an app that behaves differently. You’ve tried publishing again, but you’re still not sure whether the problem is your project or Figma.

When Figma Make works in preview but fails after publishing, first check that you’re testing the actual published URL and latest published version. Then isolate whether the failure affects access, routing, assets, browser code or an external service. A successful interactive preview doesn’t prove that the public deployment has the same permissions or dependencies.

Preview and published Figma Make apps are not the same thing

Figma Make lets you run an interactive preview and publish a web app to its own public address, normally under a figma.site domain. The preview and published version are accessed differently and may have different access settings.

Figma’s publishing documentation confirms that changes in the editor don’t automatically appear on the public site. You need to publish an update. It also explains that published access can be restricted for eligible organisation plans, and that a preview link has separate sharing permissions.

Before investigating code, copy the public URL from the Publish panel and open it outside your existing logged-in session. Don’t rely on a bookmarked preview link or a screenshot taken in the editor.

Write down the precise difference. Does the public URL refuse to open? Does the first page load but another route fail? Are elements missing? Does a button work but an API request return an error? Those symptoms point to different causes.

Check whether the latest version was actually published

Open the Figma Make file and inspect its publication status and last published date. If you’ve edited the project since that date, the live version may simply be older.

Use the Update action in the publishing interface, then open the public URL in a private browser window. Make one controlled, visible change that doesn’t touch customer data or business logic, such as revising a heading in a test copy, and confirm whether it appears on the published version.

If publishing reports an error, record the exact wording and time. Figma’s documentation acknowledges that a publish can occasionally fail and recommends retrying after a short period. Repeatedly changing generated code in response to a platform publishing failure won’t necessarily help.

Be careful with old versions. If you’ve made several edits since the last working release, preserve the current project state and record what changed before attempting a broad rollback. You need to know which revision you are comparing.

A blank published page needs a different investigation from a 404

A 404 usually means the requested address or route can’t be found. A blank screen with an HTTP 200 response can mean the HTML loaded but the browser couldn’t run the application. A visible error message may be generated by the app itself.

Start with the exact URL, including its path. Try the home page, then a direct link to the broken page. If the home page works but refreshing a nested route fails, note that route specifically. A client-side navigation problem and a hosting-route problem may produce a similar experience to the visitor but need different fixes.

Open the browser developer tools if you’re comfortable doing so. Check the Network tab for failed script, stylesheet and API requests. Check Console for the first meaningful error, not just a long list of follow-on warnings. Record the HTTP status and requested path but remove tokens, cookies and personal information before sharing anything.

If a script bundle is missing, the publish may have produced an incomplete or stale asset reference. If scripts load but throw an exception, the generated code or a runtime dependency may be the issue. If the document is blocked before the application starts, focus on access and publication settings first.

Check who is allowed to view the published app

One of the easiest mistakes is sending someone the right-looking link with the wrong access settings. Figma Make supports public publication and, for eligible organisation plans, restricted internal publication.

The Figma Make guide explains that internal sites can be accessible to members while outsiders cannot open them. Publishing administrators can also restrict the available audience. Password protection, where enabled, applies to the published address, not necessarily to your preview.

Test using an account that does not belong to your organisation. If external customers are meant to visit the app, confirm that the actual published access policy allows them to do so. Don’t solve a permissions issue by making an internal business tool public without checking what data and functions it exposes.

A site can be intentionally private and still be working correctly. The question is whether the published access matches the intended audience.

Look for missing assets and fonts

Your preview may display an image or font that isn’t available to ordinary visitors after publication. Figma’s publishing interface includes missing-font warnings because browsers need usable web-font files to render custom typography.

Compare the published page with preview. If text changes size or alignment, check whether a font request failed. If images are absent, inspect whether they came from a third-party host, require authentication or return an error. Some assets imported while prototyping may have different usage rights or availability after publication.

Don’t start by changing the whole layout. Find one missing asset, inspect its URL and permission requirements, then decide whether it should be bundled with the app or hosted through an appropriate public service.

Keep licensing in mind as well. An asset being visible in a prototype doesn’t necessarily grant permission to redistribute it on a commercial website.

Test forms, integrations and live data separately

Sometimes the public interface loads, but submitting a form, retrieving records or signing in fails. That is a functional error, not necessarily a publishing error.

For each failed feature, record the user action, the request it sends, the response code and whether the dependency is managed by Figma or an external service. Check allowed origins, callback URLs, authentication state and where credentials are stored. The deployed URL may differ from the preview origin, which matters when an API only accepts configured domains.

A form that appears successful but doesn’t store the submission is particularly dangerous for a business. Test using an ordinary visitor account and confirm the result in the intended destination, not just by seeing a success message.

Do not place secret API keys in browser code to overcome an access error. If the integration needs private credentials, it must use a suitable server-side component or another supported secure design.

Could the custom domain be the problem?

If the default figma.site address works but your own domain does not, separate the domain problem from the app itself. Check the exact DNS records against the current Figma instructions, whether the domain has been verified and whether HTTPS is functioning.

Avoid repeatedly changing DNS without documenting the original records. Changes can take time to become visible across resolvers, and conflicting old records may direct visitors to the wrong service.

Keep testing the default published address while troubleshooting the custom domain. If both fail in the same way, the domain probably isn’t the only issue. If one works, you have a useful starting point for a more targeted investigation.

When should you stop asking Make to regenerate the project?

After two or three unsuccessful attempts, uncontrolled prompts can make it harder to establish what originally broke. You might fix one screen while altering routes, forms or styling that were previously working.

Preserve the last known good state. Record the project URL, public URL, publish time, access setting, device and browser, a reproducible set of steps and the first relevant error. Check Figma’s service status and support guidance if the failure looks like a publishing-platform incident.

My broader guide to AI apps that work in preview but fail when live explains the general environment differences. This article is concerned with Make’s own preview, publication and access behaviour.

Getting a Figma Make publishing problem properly diagnosed

If this is only a private experiment, the documented publishing and access checks may be enough. If you’ve already sent a live app to customers or promised an interactive service, you need to know which part is failing before making further changes.

Through AIWebsiteRepair.com, I can carry out a paid diagnostic of the published behaviour, code and external dependencies where access allows it. I’ll distinguish problems that can be repaired in the project from Figma-side faults that must be escalated. Any implementation would be separately agreed.

My recommendation: compare the exact published version with preview, identify the first failing request or access restriction, and make only the change supported by that evidence.