Editorial illustration.
You publish a Drupal change, refresh the page and still see yesterday’s text. A colleague sees the new version. A private browser window shows something different again. The natural response is to clear every cache and hope.
That sometimes hides the symptom, but it does not explain the cause. Drupal caching can involve rendered output, dynamic page responses, aggregated CSS and JavaScript, a reverse proxy or CDN, the browser, and even a deployment that never reached the server you are testing. A calm diagnosis is faster than repeatedly pressing a purge button.
Quick Answer
First identify what is stale: page content, a CSS or JavaScript asset, an image, or an entire host. Then test the same URL while logged out and logged in, compare response headers and confirm that the new code or configuration is on the server. Clear the narrowest relevant cache, rebuild when configuration or code requires it, and test again from a clean session.
Do not disable Drupal caching on a production site as a permanent fix. Caches are part of normal performance and correctness. The useful question is which layer has an old representation and why it was allowed to keep it.
Know the layers you are testing
Drupal has internal caches that help avoid rebuilding the same page and configuration repeatedly. Rendered output may be reused when the underlying cache metadata says it is still valid. Dynamic page caching can serve responses for anonymous visitors. A reverse proxy or CDN may store an HTTP response outside Drupal.
Assets add another path. Drupal can aggregate CSS and JavaScript into generated files. A page may contain fresh markup while still referring to an old asset URL, or a browser may retain a file whose URL did not change. Images can be cached independently from both the page and the asset bundle.
The layers are not interchangeable. Clearing Drupal caches does not necessarily remove a copy held by a browser or external CDN. Purging a CDN does not fix a deployment that never uploaded the changed template.
A practical troubleshooting workflow
1. Describe the stale object precisely
Write down the URL, the expected change, the observed result, the time you deployed and whether you were logged in. “Drupal is cached” is too broad to guide a fix. “The article body is old for anonymous visitors, but the new text appears for an administrator” is useful evidence.
Check a page, an asset and an image separately. If only CSS is old, do not begin by rebuilding the database or deleting unrelated caches.
2. Confirm the deployment target
Before touching cache, verify that the changed file, configuration import or content edit reached the environment you are testing. Check the hostname, branch, container or release identifier. A stale page is sometimes a fresh response from the wrong server.
For code and configuration changes, inspect the deployment log and the current release directory. For content changes, confirm that the edit was saved and published. A cache purge cannot publish an unsaved draft.
3. Compare anonymous and authenticated views
Open a private browser window or use a session that is not logged in. Drupal often treats authenticated and anonymous traffic differently, and the difference can reveal whether dynamic page caching or a permission-dependent response is involved.
Do not use an administrator view as proof that visitors see the same page. Test the path, language, query string and host that ordinary visitors actually use.
4. Inspect response headers and asset URLs
Use the browser’s Network panel or a command-line HTTP client to inspect the response. Look for cache-related headers, the final URL, the response age and any proxy indicators supplied by your hosting stack. The exact header names vary, so interpret them with your platform’s documentation.
For CSS and JavaScript, inspect the requested filename. If the asset URL contains a new generated identifier after a rebuild, the browser has a clear way to request a new file. If the URL stays the same while its contents change, a long-lived intermediary cache can continue serving the previous bytes.
5. Clear the narrowest Drupal cache
Use Drupal’s documented cache-clearing operation for the environment. With Drush, the common cache-rebuild command is drush cache:rebuild, often shortened to drush cr. Run it with the correct site and release context, and record what you did.
A cache rebuild is suitable when Drupal needs to rebuild its caches after a code or configuration change. It is not a substitute for importing configuration, running database updates or deploying the actual code. If the change has a specific update procedure, complete that procedure first.
On a busy site, schedule broad operations responsibly. A rebuild can create a short period of extra work as caches warm again. Follow the hosting and Drupal version guidance for the installation instead of copying a command from an unrelated environment.
6. Rebuild or invalidate generated assets when needed
If markup is new but the page still looks old, check aggregated asset settings and the generated CSS or JavaScript files. Rebuild them through the normal Drupal workflow, then verify that the HTML points to the new asset URL.
Avoid manually deleting generated files unless the platform documentation tells you to. A deployment process may recreate them with the wrong ownership or on only one web node. The durable fix is a repeatable build and release procedure.
7. Check the reverse proxy or CDN separately
If the origin returns the new content but visitors receive the old response, the stale layer is outside Drupal. Confirm the cache key, host, path, query-string rules and invalidation policy with the proxy or CDN provider.
Do not purge an entire site when one route is wrong unless there is a clear reason. A targeted invalidation is easier to measure and less disruptive. After purging, test from an anonymous session and from a second network when the issue is important.
Common mistakes to avoid
The first mistake is clearing every layer at once. That can make the page appear fixed while removing the evidence needed to understand the bug. Another is disabling all caches in production, which may hide an invalidation problem while creating a performance problem.
Do not assume a private window proves the origin is fresh. It bypasses some browser state but not necessarily a shared proxy or CDN. Do not compare two URLs that differ in language prefix, query string or hostname and call them the same test.
Finally, do not edit generated CSS or HTML directly as a permanent solution. Fix the source template, configuration or build step, then perform the documented rebuild.
My Take
Cache troubleshooting is really a lesson in boundaries. Once you name the object that is stale and the layer that owns it, the solution is usually ordinary: deploy the missing change, rebuild Drupal, invalidate the correct asset or purge the correct edge response. “Clear cache” is an action; diagnosis is the skill that prevents the same confusion next week.
Bottom Line
Separate content, configuration, assets, origin responses and edge caches. Confirm the deployment, compare anonymous and authenticated views, clear only the relevant Drupal cache, and verify the final response from a visitor’s perspective.