BRYME TECH
SEPTEMBER 2026 · THE TOOL DESKPractical technology. No theatre.
THE BRYME

Practical guide · verified against the real thing

Why is GitHub Pages not showing my changes?

In one line: Branch, cache, base path: the three places a deployed change hides — and the project-page trap that breaks assets.

The symptom: you pushed, GitHub says the Pages deployment succeeded, and the live site still shows yesterday. Or the text updated but the stylesheet and images went missing. GitHub Pages has three classic hiding places, and one infamous trap.

Likely causes, most common first

1. The change is not on the branch Pages publishes (very common): Pages can serve from main, from main's docs folder, or from a gh-pages branch — and your push may have gone to a different one. Check the commit hash GitHub shows for the deployment against git log origin/<branch>. Pushing to the wrong remote or a fork is the same disease.

2. The build didn't run, or built nothing new (common): Pages builds can queue, and a failed or skipped workflow looks like silence. The Actions tab — not the site — is the source of truth: red build, no deploy; green build with an old timestamp, wrong branch.

3. Caching (common, and partly out of your control): your browser caches aggressively. Hard-refresh with cache disabled or a private window before blaming GitHub; GitHub's own CDN may also serve the prior version briefly.

4. The project-page base-path trap (the infamous one): a project site serves at username.github.io/repo-name/, not the domain root. Absolute paths like /style.css resolve to username.github.io/style.css — a different place entirely — so the HTML updates and every asset 404s. Relative paths (or a configured base URL in your generator) are the fix; custom domains remove the prefix entirely.

5. Jekyll interference (occasional): Pages runs Jekyll by default, which ignores files starting with underscores and can alter processing. Files that vanish mysteriously are usually sitting in an underscore folder or were excluded by default; a .nojekyll file at the root opts out for sites that need no processing.

Diagnosis, in order

Confirm the commit is on the right branch → open the Actions tab and read the latest deployment (status and timestamp) → load the site in a private window (kills the cache variable) → view the exact asset URL that is failing and read its full path — the base-path trap is visible in the address bar. This mirrors the three-family triage in why won't my website deploy, just with GitHub's specifics.

When this fix will not work

DNS problems on a custom-domain Pages site are DNS problems, not Pages problems — the deployment can be perfect while the domain answers at the wrong place (the DNS diagnostic; and the ordering that avoids the downtime trap is in custom domains: the DNS order). And a repository over its Pages size limit or bandwidth quota serves stale or error states that no amount of re-pushing changes.

Official documentation (checked 11 September 2026): GitHub Pages docs — configuring a publishing source, about custom domains and GitHub Pages, and Pages troubleshooting (docs.github.com/pages).

Next

Related on this desk.