Skip to content
CH SCShop classdrupal · beginner · ~25 min · 5 steps

How to clear Drupal caches (and know which one to clear)

Understand Drupal's cache layers well enough to clear the right one — and stop using a full rebuild as the fix for everything.

August 10, 2026 · by Dane Petersen

“Clear the cache” is the duct tape of Drupal advice — it usually works, and it teaches you nothing. Knowing which cache holds your stale content makes you faster at fixing things and better at guessing what broke. You’ll need Drush set up and about twenty-five minutes. No production heroics required; this is a lesson best learned on a local or staging copy.

Learn the layers before you clear them

Drupal caches in layers, each catching what the one above missed:

  • Internal page cache — whole pages, served to anonymous visitors. The big one for public traffic.
  • Dynamic page cache — pages for logged-in users, minus the personalized bits.
  • Render cache — individual chunks: blocks, menus, rendered nodes. This is usually where “I edited it but the page didn’t change” lives.
  • Twig cache — your templates, compiled to PHP. Template edits hide here.

Above all of these sit your browser and any CDN — worth remembering before you blame Drupal for a page only you see as stale.

Clear everything the blunt way

The command everyone knows:

drush cache:rebuild

(drush cr for short.) It empties every layer and rebuilds Drupal’s internals. It always works, and that’s its flaw: on a busy site the next few page loads are slow while every cache refills from zero, and you’ve learned nothing about what was actually stale. Fine on your laptop; a small toll on production at noon.

Clear just the one you need

Match the symptom to the layer and clear only that:

drush cache:clear render          # a block, menu, or listing is stale
drush cache:clear css-js          # styles or scripts didn't update
drush cache:clear theme-registry  # a new template file isn't picked up
drush cache:clear router          # a new page or route 404s

Run drush cache:clear with no argument and it politely lists your choices. The habit to build: when a targeted clear fixes it, you’ve just diagnosed the problem. When only drush cr fixes it, note that too — it tells you the problem lives deeper, often in the container or a module’s own cache.

Turn off caching locally while you build

If you’re doing theme work, stop clearing caches in a loop and turn them off where it’s safe. Since Drupal 10.1 there’s an admin page for exactly this: Configuration → Development → Development settings (/admin/config/development/settings). Turn on Twig development mode and “Do not cache markup,” and your template edits show up on refresh.

Two honest warnings: this belongs on local and staging only — a production site with caching off is a canoe with no bottom — and anonymous page caching still applies, so view your work logged in. Turn it back off when you’re done building.

Verify with a change you can see

Prove the layers are real. Add an obvious line to any template in your active theme — a <p>hello from the template</p> in page.html.twig works. Refresh: no change, because the compiled Twig and render layers are still serving the old version. Clear the blunt way:

drush cache:rebuild

Refresh — your line appears. Now turn on Twig development mode from the previous step, delete the test line, and refresh again. It’s gone instantly, no clearing at all. You’ve now seen the same change move through the site three ways: blocked by cache, forced through with a rebuild, and flowing freely in development mode. Once that clicks, “clear the cache” stops being a superstition and starts being a choice.

That's the lesson. Back to the shop for more — or if this is the chore your organization never gets to,that's literally what we're for.