If Jekyll generated the new stylesheet but the deployed page still looks old, first compare the built file with the CSS returned by the public URL. When the bytes differ because a browser or CDN cached the unchanged asset URL, add a build-specific version to the stylesheet link.
Last updated: November 14, 2026.
<link rel="stylesheet"
href="{{ '/assets/css/main.css' | relative_url }}?v={{ site.time | date: '%s' }}">The query string changes on each Jekyll build, so a cache sees a new asset URL. Keep the normal relative URL filter so sites hosted below a subpath still resolve correctly in every deployed environment.
Identify which cache is stale
Inspect _site/assets/css/main.css immediately after the build. If it is old, remove the local build cache and rebuild with bundle exec jekyll clean followed by bundle exec jekyll build. If the built file is current, request the public CSS URL directly and inspect response headers such as Age, Cache-Control, and ETag.
Jekyll’s asset documentation explains its built-in Sass processing and generated asset paths. Confirm that the page links to the same file you inspected; multiple themes, base URLs, or deployment directories can make the browser request a different stylesheet.
Prefer versioned asset URLs
Jekyll exposes build information to Liquid templates, and its Liquid filter documentation covers filters used in output templates. A build timestamp is a simple cache key for small sites. Content-hashed filenames are better for larger pipelines because unchanged assets keep the same URL while changed bytes receive a new one.
Do not disable caching globally just to solve one stale file. Long-lived caching is valuable when URLs are versioned. After deployment, view the generated HTML, open a private browser window, and confirm the versioned CSS request returns the new bytes. Check both desktop and mobile entry pages because older layouts may reference another bundle. Purge the CDN only when an incorrect response is still cached under a URL that cannot be changed.
