Why is website not displaying correctly: 3 causes

The page opens, the header shows, and the content looks partly wrong. Sometimes the styles never arrive, so the text stacks in plain black on white with the default font. Sometimes a block that should hold prices or reviews is empty, because the script that fills it failed or was refused. Sometimes the browser refuses a file for its security rules, such as an http image on an https page. The owner sees the finished page on their own machine, where files are cached from the last visit, so the fault stays hidden.

• Reload with the Network tab open and look for red rows: 404 responses, or requests marked failed or blocked.
• Read the Console on load for messages about mixed content, a refused script, or a blocked font.
• View the page source. Content missing from it came from the server or a fetch; content missing only on screen points to a script.
• Open the same page in a private window, with the cache cleared, and compare it with your normal window.
• Check the page head for a charset declaration, since its absence can garble accented letters and currency signs.

A missing stylesheet is the easiest of these causes to read. The page keeps its HTML, so the headings and links are present, but the layout, colors and spacing are gone. A missing script leaves a different mark: the page looks finished, yet the parts a script draws stay empty, such as a pricing grid, a map or a list of reviews. Both come from the same place, a request that did not complete. The difference is which request failed, and the Network tab names it.

Browsers refuse some files on purpose. A page served over https that loads an image or script from an http address gets blocked as mixed content, and the Console says so. A Content Security Policy lists the sources a page may load from, and it refuses anything from a host it does not list, such as a font from a new provider or a chat widget. The file exists and the server answered, but the browser never handed it to the page. Look for the message in the Console, which names the source that was refused.

Your browser keeps copies of pages and files, and so can a network between you and the server. After a release, a visitor can receive a cached page that points at the old stylesheet name while the server now holds only the new one, or the reverse. Some visitors see the new layout and others the old one, depending on which copy their browser or network holds. A hard reload in your own browser may fix it for you and leave the visitor with the broken copy. A private window on mobile data comes closer to what a visitor gets.

Each deploy can rename a stylesheet or a script, so a page cached last week can point at a file that no longer exists. Rerun the same phone visitor after each release, from a private window, and check that the plan table fills in. With paid credits, visitors can open a page behind a site password, so the same check runs on each preview deploy before a visitor sees it.