How to Tell If a Website Is Built With Drupal

Drupal is one of the most powerful open-source content management systems, favoured for large, complex and security-sensitive websites where WordPress would struggle to scale. If you want to know whether a site is built with it, the quickest answer is to type drupalSettings into the browser console — a returned object confirms it immediately — or to look for asset paths under /core/ and /sites/ in the page source. This guide walks through every reliable signal, the architecture that produces them, and what a Drupal build tells you about the organisation behind it.

What is Drupal?

Drupal is a PHP-based, open-source CMS first released in 2001 and maintained by a large global community. Where WordPress optimises for ease of use and a vast plugin ecosystem, Drupal optimises for structured content, flexibility and scale. Its content model — entities, fields, content types, taxonomies and views — lets developers build sophisticated information architectures that would be awkward in simpler systems, which is why it underpins so many government portals, university sites, NGOs, large publishers and enterprise platforms. It has a strong reputation for security and a formal release cadence, and modern Drupal (version 8 onward) is built on the Symfony PHP framework, giving it a thoroughly object-oriented, API-friendly foundation.

For detection purposes, the important context is that Drupal is rarely a casual choice. Standing up and maintaining a Drupal site usually involves developers or a specialist agency, so finding Drupal almost always signals an institutional or enterprise project with a real budget, structured-content requirements and an established team. Drupal is also increasingly run in a decoupled or "headless" configuration, where it serves content through its JSON:API or GraphQL to a separate front end — a pattern that changes which signals you will see, as discussed below.

How Drupal renders and exposes itself

A traditional, themed Drupal site exposes a consistent set of fingerprints rooted in its architecture. Modern Drupal passes server-side configuration to the browser through a global JavaScript object called drupalSettings, populated from an inline script tag with the id drupal-settings-json. Its JavaScript behaviours attach through the Drupal.behaviors pattern, and rendered markup is sprinkled with data-drupal-* attributes (for example data-drupal-link-system-path). Static assets load from Drupal's well-known directory structure: core files under /core/, uploaded files under /sites/default/files/, and modules and themes under /modules/ and /themes/ (legacy Drupal 7 used /sites/all/modules/ and /sites/all/themes/).

The server also tends to announce itself. Drupal commonly sends an X-Generator response header and includes a <meta name="generator"> tag, both of which often read something like Drupal 10 (https://www.drupal.org) — revealing the major version. You may also see a X-Drupal-Cache or X-Drupal-Dynamic-Cache header from its caching layer. Knowing this architecture — the settings JSON, the behaviours, the data attributes, the /core/ and /sites/ paths, and the generator signals — makes detection straightforward even on a heavily customised theme.

How to tell if a website uses Drupal

Confirm at least two of the following.

1. Use the console. Type drupalSettings (Drupal 8+) or Drupal and press Enter. A returned object — especially one with Drupal.behaviors — is a strong, immediate confirmation. Legacy sites expose Drupal.settings.

2. View the page source. Search the HTML for drupal. Look for the drupal-settings-json script, data-drupal-* attributes, and asset references under /core/, /sites/default/files/, /modules/ and /themes/.

3. Check the response headers. In the Network tab, inspect the main document's response headers for X-Generator: Drupal ... and any X-Drupal-Cache headers. The generator header reveals the major version.

4. Read the generator meta tag. A <meta name="generator" content="Drupal 10 (https://www.drupal.org)"> tag is an explicit declaration, when the theme has not removed it.

5. Probe well-known paths. The login route at /user/login and the admin at /admin are Drupal conventions; a /core/ directory and a CHANGELOG.txt historically confirmed Drupal, though modern sites often restrict these.

What the Drupal signals look like

<script type="application/json" data-drupal-selector="drupal-settings-json">{"path":{...},"ajaxPageState":{...}}</script>
window.drupalSettings = { path: {...}, user: {...}, ... }
GET /core/misc/drupal.js
GET /sites/default/files/styles/large/public/image.jpg
Response header: X-Generator: Drupal 10 (https://www.drupal.org)

The combination of the drupalSettings global, the /core/ and /sites/ asset paths, and the X-Generator: Drupal header is conclusive.

Drupal versus similar systems — avoiding false positives

Drupal's fingerprints are distinctive, but a few situations require care. A decoupled Drupal back end serving a React or Next.js front end will not expose drupalSettings or /core/ paths on the public site — instead you may see JSON:API calls to /jsonapi/ or a GraphQL endpoint, and image styles served from a Drupal files path. In that case, network requests to a Drupal API are the giveaway. Do not confuse Drupal with WordPress (which uses /wp-content/, /wp-includes/ and the wp- prefix) or Joomla (which uses /media/system/, option=com_ URLs and a Joomla generator tag) — each has its own clear signatures. Finally, security-conscious Drupal sites often strip the generator meta tag and restrict access to CHANGELOG.txt and /core/install.php, so rely on the drupalSettings global and the asset paths rather than expecting every signal to be present.

How reliable is each Drupal signal?

The drupalSettings global (with Drupal.behaviors) is definitive for a traditional Drupal front end. The /core/, /sites/default/files/ and /modules/ asset paths are equally strong because they reflect Drupal's fixed directory structure. The X-Generator: Drupal header is conclusive when present and reveals the major version. The generator meta tag is reliable but is sometimes removed for security. Probing /user/login is supportive but not definitive on its own. For decoupled sites, JSON:API or GraphQL traffic to a Drupal back end is the key signal. As a rule, the settings global plus an asset-path match settles it; for headless setups, follow the API.

What a Drupal build reveals about an organisation

Finding Drupal is a strong indicator of an institutional, enterprise or content-heavy organisation. Its sweet spot — structured content, multilingual support, granular permissions, strong security and the ability to model complex information — means it is chosen deliberately by governments, universities, healthcare and financial institutions, large NGOs, and media companies. So a Drupal site usually implies a real budget, a development team or specialist agency, and requirements that outgrew simpler tools. If you sell hosting, security, accessibility, development or migration services, a Drupal build identifies an account with both the complexity and the resources to need them. The major version visible in the generator header is also actionable: an older Drupal 7 site (now end-of-life) is a strong migration prospect, while a current Drupal 10 site signals a maintained, modern platform.

Drupal in a modern stack

Drupal sites span a spectrum from fully traditional to fully decoupled, and where a site sits tells you a lot. A classic themed Drupal site pairs the CMS with a PHP hosting environment, often a reverse proxy or CDN (Varnish, Cloudflare or Fastly) for caching, and frequently a platform like Acquia, Pantheon or Platform.sh that specialises in Drupal hosting — finding those is a strong corroborating signal. A decoupled Drupal pairs the CMS back end with a modern JavaScript front end and edge hosting, communicating over JSON:API or GraphQL. For an auditor, the valuable details are the major version (from the generator header), whether the site is traditional or decoupled (from the presence of drupalSettings versus API traffic), and the hosting platform; together these reveal not just that the site runs Drupal but how modern and well-resourced the implementation is.

A quick Drupal confirmation walkthrough

Open the site with developer tools on the Console panel and type drupalSettings — a returned object is your fastest confirmation; try Drupal on older sites and check for Drupal.behaviors. Switch to the Elements or Network panel and search for asset paths under /core/ and /sites/default/files/. In the Network tab, click the main document and read its response headers for X-Generator: Drupal. Finally, view the source for the drupal-settings-json script and any generator meta tag. If drupalSettings is absent but you suspect a decoupled build, watch the Network tab for /jsonapi/ or GraphQL calls to a Drupal back end.

A quick Drupal detection checklist

• Type drupalSettings (or Drupal) in the console; a returned object is conclusive.
• Search the source for the drupal-settings-json script and data-drupal-* attributes.
• Look for asset paths under /core/, /sites/default/files/, /modules/ and /themes/.
• Read the X-Generator response header and the generator meta tag for the version.
• For decoupled sites, watch for /jsonapi/ or GraphQL calls to a Drupal back end.
• Note the hosting platform (Acquia, Pantheon, Platform.sh) as corroboration.

Detecting Drupal at scale

Checking one site by hand is quick, but auditing many — for example, to find ageing Drupal 7 sites ripe for migration, or to map enterprise CMS usage across a sector — calls for automation. StackOptic detects Drupal (traditional and decoupled), its major version where exposed, and thousands of other technologies from a real browser. For related reading, see our guide to telling what CMS a website is using and the full Drupal technology profile.