## TL;DR
"The page won't load" is three different problems wearing one sentence: their browser, their network, or your servers. Check your status page first so you never debug a user's laptop during your own outage, then walk the user through cache, DNS, and VPN in that order. The order matters because each step rules out a layer.

## The query

```text
"page won't load" support script: cache, DNS, VPN
```

## Use this when

- A page is blank, stuck loading, or times out
- The site loads for you but not the user
- Only one user or office is affected
- The problem started suddenly with no changes
- You are writing the page-load macro

## Not for

- Errors that appear after the page loads fine
- Login failures on a working page
- Outages affecting everyone
- Slow pages that do load eventually

## Steps

### 1. Check your status page before touching anything

If your systems are degraded, say so immediately and stop debugging their machine. Nothing burns trust like twenty minutes of cache-clearing during your own incident.

Expected output: outage confirmed or ruled out in under a minute.

### 2. Get the exact symptom and the exact URL

Blank white page, spinner forever, browser error text, or timeout. Ask them to copy any error text word for word and confirm the URL they used. "It doesn't work" plus a screenshot beats three rounds of guessing.

Expected output: the symptom described precisely, with the URL.

### 3. Try incognito and a different browser

An incognito window skips cache, cookies, and most extensions in one move. If the page loads there, the problem is their normal browser state, and you go to the cache-clear playbook. If it fails there too, it is network or server.

Expected output: the browser layer confirmed or eliminated.

### 4. Flush DNS and rule out stale resolution

Have them flush the local DNS cache: on Windows, open Command Prompt and run ipconfig /flushdns; on Mac, restart the browser or reboot. Then retry. Stale DNS sends them to a dead server long after you fixed things.

Expected output: fresh DNS resolution, or the step ruled out.

### 5. Check VPN, proxy, and corporate filtering

Ask if they are on a VPN or office network, and have them disconnect the VPN or try a phone hotspot. Corporate proxies and VPNs break or block sites constantly, and the fix is on their network side. If the hotspot works, you have your answer.

Expected output: VPN or proxy confirmed as the cause, or ruled out.

## Ready-to-use message

```text
Let's narrow this down. First, can you send me a screenshot of
what you see, and confirm the exact page address?

Then try this in order:
1. Open the page in an incognito/private window. If it loads
   there, it's your browser's saved data, and I'll walk you
   through clearing it.
2. If you're on a VPN, disconnect it and retry. Office VPNs
   block sites more often than you'd think.
3. Try your phone's hotspot. If the hotspot works, the issue
   is your office or home network, not our site.

Tell me which step changes things and we'll go from there.
```

## Variant phrasings

### website not loading but internet works

Steps 3 through 5. Browser state, then DNS, then the network path.

### page stuck on loading spinner

Steps 2 and 3. Pin down whether it is truly stuck or erroring silently, then incognito.

### site won't load on office wifi but works at home

Step 5 first. That pattern is the corporate network until proven otherwise.

## Why it happens

Loading a page is a chain of about six handoffs: DNS lookup, connection, security check, server response, then the browser assembling the pieces. A failure at any link looks identical to the user, which is a blank page. The script works because it tests each link in order instead of guessing, and the hotspot test is the great divider between "your machine" and "your network."

## Edge cases

- Fails in every browser and on hotspot: now it is either your servers or their ISP. Check your status page again and escalate with the evidence trail.
- Only one specific page fails: that page or its data is the problem, not the network. Get the URL and check it yourself.
- Works on wifi but not mobile data, or vice versa: carrier-level filtering or IPv6 quirks. Note the pattern for engineering.
- The user is in a country with heavy filtering: be honest that access may be restricted there, and do not promise workarounds you cannot support.
- Intermittent loading: ask for timestamps of failures. Patterns in time point at server load or scheduled jobs, not the user's setup.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g8Vl3cbotvXoAu2c7uB8sQ