A website app that misbehaves almost always misbehaves in one of eight ways, and each has one cause. This page is ordered by how often each one comes up. If the app opens to a white screen, read the first section and stop — it is very likely the answer.
1. Blank white screen (bundled HTML or ZIP)
Cause: <script type="module">. Bundled pages are served from a file:// origin, and browsers refuse to load module scripts across file origins. Your page's HTML renders, its JavaScript never runs, and if the JavaScript builds the page — as every React, Vue and Svelte app does — the result is nothing. Vite and most modern templates emit module scripts by default.
Fix: build a classic script. In Vite, add @vitejs/plugin-legacy or set the build target so the output uses a normal <script>; in hand-written pages, drop type="module" and use a bundler or plain scripts. Then check the output with the validator, which flags module scripts along with the next two causes.
2. Page loads but styles and images are missing
Cause: absolute paths. /css/style.css means "from the root of the server", and there is no server inside an app. The same happens with paths to your own computer that an editor wrote for you, and with references that differ from the filename in case — Logo.PNG versus logo.png — because Android's filesystem is case-sensitive.
Fix: relative paths (css/style.css) and lowercase filenames throughout. Static-site generators have a base-path or relative-URLs setting; set it before exporting.
3. Some content missing on a URL app
Cause: mixed content. Your page is HTTPS but an image, script, iframe or font is loaded over plain HTTP, and the app blocks it exactly as modern Chrome does. Common with old embedded maps, videos and third-party widgets.
Fix: change the embed to https://. If a resource has no HTTPS version, replace it. Chrome's developer tools list every mixed-content request on the desktop version of your site.
4. Site does not load at all in a URL app
Cause: the site forbids embedding. A X-Frame-Options: DENY or a Content Security Policy with frame-ancestors 'none' header, set by a security plugin or a hosting default, can stop the page rendering in some WebView configurations. Less commonly, the site blocks the WebView's user agent as a "bot".
Fix: allow your own origin in those headers, or remove them for the mobile site. On WordPress the usual culprit is a security plugin's "clickjacking protection" setting.
5. "Sign in with Google" fails inside the app
Cause: Google refuses to show its sign-in page in embedded WebViews — a deliberate security policy, not a bug in the app. The button opens, then errors with "disallowed_useragent" or simply does nothing.
Fix: use email or password login, magic links, or another provider inside the app. If Google login is essential, have the site open it in the system browser and return via a link. Native Google sign-in is not something a website app can add.
6. Links to other sites trap the user
Cause: the app opens every link inside itself, so a link to your supplier's or a partner's site leaves the user on a foreign page with no way home.
Fix: the builder opens links to other domains in the phone's browser and keeps your own domain inside the app. If a link to your own domain is opening the browser, check whether it points at a different domain — shop.example.com versus example.com — and decide which the app should own.
7. The back button closes the app immediately
Cause: the site navigates with JavaScript that replaces the page instead of pushing history, so from the WebView's point of view the user has never left the first page. One tap of Back, and there is nowhere to go but out.
Fix: use normal links, or history.pushState for in-page navigation, so each screen is a history entry. Single-page apps with hash routing get this for free. The shell steps back through history and only exits at the start.
8. File uploads and camera inputs do nothing
Cause: <input type="file"> needs the app to provide a file chooser and, for photos, camera permission. A bare WebView silently ignores the tap.
Fix: the builder wires the file chooser for you; if your pages take photos, enable the camera permission when you build. Location inputs likewise need the location permission enabled, and the site must ask over HTTPS.
If none of these is it
Open the same page in Chrome on an Android phone. If the problem is there too, it is the website, and Chrome's remote debugging will show the error. If it only happens in the app, note the exact page and what you tapped, and tell us — the two together are usually enough to find it.