Website app not loading? The fixes

When a converted website app opens to a blank screen or will not load, the cause is almost always one of a short list: the site is not HTTPS, it loads something over plain HTTP (mixed content), a security header forbids embedding, a sign-in bounces through a domain that refuses WebViews, a popup expects a second window, a bundled page uses ES modules, or the first paint is simply slow and looks blank. Below is each one with the symptom, the test in Chrome, and the fix.

First, the fastest test

Open the site in Chrome on an Android phone. The app uses Chrome's engine, so if it fails there it fails in the app, and Chrome will show you the error the app hides. If it works in Chrome and not the app, the cause is one of the WebView-specific items below (3, 4, 5, 7).

1. The site is HTTP, not HTTPS

Symptom: blank page, or "net::ERR_CLEARTEXT_NOT_PERMITTED" if errors are visible.
Why: Android blocks plain-HTTP traffic from apps by default since Android 9.
Fix: serve the site over HTTPS. Certificates are free (Let's Encrypt; most hosts do it in one click). Rebuild with the https:// address.

2. Mixed content

Symptom: the page loads but images, scripts or a stylesheet are missing; a form or a map does not work.
Why: an HTTPS page is loading some resource over http://, which the WebView blocks.
Test: Chrome's DevTools console on desktop lists each "Mixed Content" block.
Fix: change those URLs to https:// (or protocol-relative). A CMS setting like "force HTTPS" or a plugin usually fixes them in bulk.

3. Frame-blocking headers

Symptom: works in Chrome, blank in the app, sometimes with a "refused to connect" line.
Why: a WebView is not an iframe and normally ignores X-Frame-Options, but some CSP frame-ancestors setups and JavaScript "framebusting" that checks window.top misfire in embedded contexts.
Test: curl -I https://yoursite.com and look for X-Frame-Options or Content-Security-Policy: frame-ancestors. Search the site's JS for top.location.
Fix: keep the headers (they protect the site) but exempt the app's user agent, or remove the JS framebuster, which offers little protection anyway.

4. Social sign-in that never finishes

Symptom: tapping "Continue with Google" shows a "disallowed_useragent" error, or returns to the login page.
Why: Google (and some others) refuse OAuth inside embedded browsers.
Fix: use email/password sign-in in the app, or a sign-in flow that completes on your own domain. Some builders open the OAuth step in the system browser and return — check whether yours does. Do not spoof the user agent; Google detects it and it violates their terms.

5. Popups and window.open()

Symptom: a button that opens a new window does nothing — payments, PDF previews, "open in new tab" links.
Why: there is no second window in a single-WebView app unless the shell supports it.
Fix: change target="_blank" links to normal links for your own pages; for external ones, the builder hands them to the system browser. For payment providers that insist on a popup, most offer a redirect mode — use it.

6. Third-party cookies

Symptom: an embedded widget (comments, a booking iframe, a chat) does not remember you or shows blank.
Why: third-party cookies are blocked by default in WebViews on recent Android.
Fix: if the widget is on your own subdomain, set cookies with SameSite=None; Secure and a parent-domain cookie. If it is someone else's, check whether they offer a first-party or cookieless mode.

7. Bundled HTML that uses ES modules

Symptom: an HTML or ZIP app opens white; the same file works when opened in Chrome from a server.
Why: <script type="module"> is blocked on file:// pages, so no JavaScript runs. This is the single most common failure for bundled apps.
Fix: bundle to a classic script (any build tool does it), or switch to the URL route and host the page.

8. The first paint is slow

Symptom: the app appears blank for several seconds, then works.
Why: a browser shows a progress bar; the app shows nothing until the page paints.
Fix: switch on a page loader in the builder so the wait is visible; then make the page faster — compress images, defer non-critical scripts, put a real <title> and above-the-fold content early in the HTML.

9. A cached failure

Symptom: you fixed the site and the app still shows the error.
Why: the WebView cached the error page or the old resource.
Fix: clear the app's storage (Settings → Apps → your app → Storage → Clear) or reinstall. For a URL app, adding a cache-busting query to the address in a rebuild also works.

A five-minute diagnosis

1. Does it work in Chrome on the phone? No → causes 1, 2, 8. Yes → continue.
2. Is the address in the builder https://? No → cause 1.
3. Does curl -I show frame headers? Yes → cause 3.
4. Does the failure happen at sign-in or on a popup? → causes 4, 5.
5. Is it a bundled HTML/ZIP app? → cause 7.
6. Did you just fix something? → cause 9.

Before any of this, the App Readiness Score asks about most of these causes as questions — it is cheaper to answer them than to debug them.