Short answer
No — not reliably. Jekyll's incremental regeneration (--incremental) tracks dependencies between documents, layouts, and includes, but content loaded from _data/*.yaml and exposed as site.data is treated as global site state rather than a per-page dependency. As a result, editing a data file often does not mark the pages that consume it as dirty, and those pages come out of an incremental build unchanged. A full build shows the update, which is the tell-tale sign.
Likely explanation vs. confirmed behavior
The likely explanation for what you're seeing is a gap in the dependency graph, not browser caching or a failed build. Incremental mode works by recording, in .jekyll-metadata, which source files each output depended on during the previous build. Because site.data is read globally and merged into the site object, the regenerator has no per-page record that "page X read _data/nav.yaml" — so when that file changes, nothing downstream is scheduled for reprocessing.
One nuance worth separating out: if you run jekyll serve --incremental --watch, the file watcher does notice the data file changed and triggers a rebuild cycle. The problem is that the incremental regenerator then decides most pages are unaffected and skips them. So you can see a build run in the log and still get stale HTML.
How to confirm this is your problem
bundle exec jekyll build --incremental
# edit a file in _data/
bundle exec jekyll build --incremental
# inspect the affected HTML in _site — is the change there?
bundle exec jekyll build # full build, compare output
If the full build differs from the incremental one, the dependency gap is confirmed. Also check jekyll --version: dependency tracking has been refined across releases, so exact staleness behavior differs between Jekyll 3.x and 4.x and between minor versions.
Workarounds that keep incremental mode
- Touch the consuming pages after a data edit so the regenerator sees them as modified:
touch pages/*.md (or the specific files that use the data). This is the cheapest targeted fix. - Delete
.jekyll-metadata (and .jekyll-cache if present) to force a full rebuild on the next run. Effective but slow on large sites. - Run a full build for deploys and reserve
--incremental for local authoring where you mostly edit posts and pages, not data files.
There is no configuration option that adds _data files to the per-page dependency graph; the workarounds above are the practical options. Note also that plugins which read data files may have their own staleness behavior independent of the core regenerator.
Caveats
Exact behavior is version- and plugin-sensitive, so treat the verification steps above as the source of truth for your setup rather than assuming any particular release has fixed the gap. If you find a version where data edits do propagate correctly, that would be worth noting in your project's README or build script.
jekyll