Does NASA Still Use Drupal in 2026? What the Numbers Actually Say

The main NASA.gov website does not run on Drupal in 2026. NASA moved its flagship web environment from Drupal to WordPress in September 2023, and the current NASA.gov belongs to that modernized platform. That is the clean answer to the narrow question.

The broader answer needs one extra sentence. NASA is not a single website. It operates a sprawling collection of mission sites, laboratory domains, archives, internal services, and public applications. I found strong evidence for the main portal's migration, but not a fresh agency-wide inventory proving that every last NASA property has stopped using Drupal. Anyone claiming either 'NASA still uses Drupal' or 'NASA has zero Drupal anywhere' should specify the domain.

Drupal itself remains widely deployed. Current measurement services disagree on the total because they measure different samples. W3Techs puts Drupal on 0.7% of all websites and 1.0% of sites with a known CMS. BuiltWith detects roughly 413,000 live Drupal sites. Those are not rival answers. One is an estimated share; the other is a detected-site count.

I would not choose a CMS because an impressive organization used it ten years ago. I choose based on content structure, permissions, multilingual work, integrations, security operations, editor needs, and the team that must keep the thing alive on an ordinary Tuesday.

For the flagship NASA.gov, no. NASA publicly launched the new NASA.gov and science.nasa.gov experience in September 2023. Its announcement described the change as part of a long-term effort to consolidate the agency's public web presence into a more coherent platform.

The strongest evidence is not visual similarity or a scanner badge. NASA's own Shutdown Furlough Guide revision history says the updated NASA Shutdown environment moved from Drupal to WordPress on September 26, 2023, with related NASA.gov URLs changing in the new environment. Current NASA.gov assets and routes also align with a WordPress implementation, but I do not need to reverse-engineer the site when NASA has already named the migration.

That wording matters. I am comfortable writing 'the main NASA.gov moved from Drupal to WordPress.' I am not comfortable turning it into 'NASA no longer uses Drupal anywhere.' Agencies can run different stacks across centers and subdomains, and technology detection becomes especially unreliable when a CMS sits behind caches, APIs, static builds, or separate frontends.

NASA.gov genuinely was a major Drupal success story. The Drupal case study describes a rapid migration, a large AWS-based platform, hundreds of thousands of pages, terabytes of content, and a multisite program used across NASA centers. That history is real. It is simply history rather than a reliable description of the 2026 flagship stack.

Old case studies rank for years. Vendor portfolio pages keep their best logos. Technology databases retain historical detections. Writers copy one another, and soon a 2017 architecture becomes a 2026 fact without anybody visiting the current site. A CMS logo can outlive the stack it describes.

When I audit a famous-site claim, I use a small evidence ladder. A current statement from the organization beats a vendor case study. A dated migration document beats an undated logo wall. Current application behavior can support the conclusion, while third-party scanners remain useful but fallible. If sources conflict, I narrow the claim instead of pretending certainty.

This is also why 'used by NASA' is weak buying evidence. NASA's old Drupal implementation solved NASA's old requirements with a particular team, contract, architecture, and budget. Your nonprofit, university department, or publishing team does not inherit those resources by choosing the same CMS.

NASA's 2023 website modernization report makes the scale problem obvious. It counted 1,777 live external domains and 810 public-facing websites in December 2023 after excluding redirects, development environments, API endpoints, web services, and employee-only properties. NASA also warned that the numbers fluctuate as sites are consolidated and decommissioned.

That report helps me interpret the CMS question. The agency launched modernized flagship sites, then continued moving content from older properties into NASA.gov and science.nasa.gov. During a program like that, different systems coexist. Some domains redirect, some remain active, some become archives, and some applications have backend technology that a public scanner cannot see.

The dated domain count is not a 2026 inventory, so I do not present 810 as today's total. I use it to establish scale and uncertainty. A person asking whether NASA uses Drupal may mean the homepage, one science center, an internal publishing platform, or any NASA-controlled domain. Those are four different research questions.

My practical conclusion is deliberately precise: NASA's primary public portal moved off Drupal. Residual Drupal use elsewhere in the agency is plausible, but I did not find current primary evidence that supports a complete count. Precision is less exciting than a logo, but it survives contact with reality.

There is no authoritative census of every Drupal installation. Drupal is open source, can run privately, can sit behind another frontend, and does not require every production site to report home. The best public answer combines multiple measurement methods and keeps their labels attached.

On July 13, 2026, W3Techs reported Drupal on 0.7% of all websites and a 1.0% market share among websites whose CMS it could identify. Its ranking breakdown is more revealing: Drupal represented 3.7% of known-CMS sites in the top one million, 6.4% in the top 100,000, 7.1% in the top 10,000, and 6.0% in the top 1,000.

BuiltWith's live technology profile reported 413,241 live Drupal websites and more than 1.5 million additional historical detections. BuiltWith also lists redirects separately. I would describe the live figure as 'about 413,000 detected live sites,' not 'exactly 413,241 Drupal installations.' Domains, redirects, parked sites, hidden backends, and detection signatures make that precision misleading.

The useful takeaway is not that Drupal owns a huge slice of the entire web. It does not. The useful takeaway is that Drupal's presence rises sharply among more heavily trafficked sites. Its modern niche is smaller than WordPress but skewed toward institutions that value structure, governance, and custom workflows.

W3Techs publishes percentages from a defined web survey. BuiltWith crawls for technology signatures and publishes domain counts. Drupal project usage reporting only sees participating installations. Each answers a different question, which is why the outputs do not line up neatly.

One Drupal installation can serve several domains. One domain can expose Drupal on a subdomain or inner page. A decoupled Drupal backend may leave little public evidence. A former site can remain in a historical database. A redirect can look live to one system and secondary to another. Detection also depends on which signatures survive caching, security hardening, and frontend architecture.

I therefore use two sentences in planning documents: an estimated market share from W3Techs and an approximate detected count from BuiltWith, both dated. I do not multiply 0.7% by a random estimate of the size of the internet. That produces a confident-looking number built from incompatible assumptions.

The version distribution deserves attention too. W3Techs still detected Drupal 7 on 30.0% of Drupal sites in July 2026, even though Drupal 7 reached end of life in January 2025. Detection is imperfect, but the signal is clear: a meaningful portion of the installed base carries legacy migration and security work.

Drupal Core remains the flexible framework underneath custom builds. Drupal CMS is the more opinionated product built on Drupal Core, bundling common capabilities for content creators, marketers, and site builders. Drupal CMS 2.0 added a visual building experience, site templates, and AI-assisted tools while keeping Drupal's structured-content foundation.

I see that effort as a response to a real market problem. Drupal can model complex relationships, permissions, moderation states, languages, media, APIs, search, and integrations. It has often made the first mile harder than competitors that arrive with a polished page builder and managed hosting. Drupal CMS wants to shorten that first mile without turning Core into a closed platform.

The new product does not erase operational responsibility. A serious Drupal site still needs hosting, Composer, configuration management, backups, monitoring, testing, security updates, deployment discipline, and people who understand how content architecture affects editors. Visual building changes authoring; it does not repeal software maintenance.

When requirements are simple, I prefer a simpler tool. When requirements are genuinely complicated, Drupal's boring strengths become valuable: structured entities, granular permissions, revision workflows, multilingual depth, open-source ownership, and the ability to build around unusual institutional rules.

I shortlist Drupal when the content model is more important than the homepage mockup. A university may need schools, departments, degrees, staff, research, events, locations, taxonomies, and delegated editors. A government program may need approval history, accessibility, records policy, multilingual delivery, and strict permissions. A publisher may need reusable media, complex categorization, subscriptions, and several delivery channels.

I do not shortlist it merely because a project might grow. Every brochure site might grow. I want visible complexity: several content relationships, many roles, moderation, localization, custom integrations, or multiple frontends. Otherwise the team pays for power it does not use and maintenance it definitely will use.

Team shape decides as much as features. A capable internal web team or experienced Drupal partner can make updates routine. A small organization with one overloaded communications manager can turn the same system into a permanent dependency on outside help. The software did not change; ownership did.

Drupal has no software license fee. That is valuable, especially for organizations that care about code and data ownership. It does not mean the site is free. I budget implementation, design, hosting, search, CDN, monitoring, backups, security response, accessibility, upgrades, and the humans who understand the architecture.

Modern Composer-based Drupal updates can be smooth on a disciplined codebase with tests and staging. They can also become slow when custom modules, abandoned contributed modules, old patches, unusual hosting, or years of deferred upgrades collide. I have learned to inspect the dependency graph before believing any maintenance estimate.

The operational plan should name an owner, an update cadence, supported PHP and database versions, backup recovery objectives, test coverage, deployment steps, and escalation contacts. If those details feel excessive for the project, that may be the clearest sign that Drupal is excessive for the project.

A 5,000-page site can be easier to migrate than a 500-page site. Repetitive, well-structured content moves predictably. A smaller site with arbitrary page-builder layouts, embedded forms, custom permissions, broken media references, and undocumented integrations can consume months.

When moving to Drupal, I inventory content types, taxonomies, users, roles, workflows, files, URLs, SEO metadata, translations, redirects, integrations, and search behavior. Then I build a mapping and run the migration repeatedly. Hand-editing production content into a new model is not a migration strategy; it is a very expensive group project.

When moving away from Drupal, I preserve the same relationships before choosing a destination. The new platform must account for revisions, references, moderation, media, aliases, redirects, and any business logic hidden in modules or themes. A simpler destination may reduce future maintenance, but the exit project still has to understand the system it is replacing.

In current Drupal discussions, I keep seeing the same split. Experienced practitioners describe smoother modern upgrades, strong structured content, and projects that would be painful to reproduce in simpler systems. Other users describe hours lost to updates, module compatibility, patches, deployment complexity, and inherited sites that took months to understand.

The complaints become sharper for small nonprofits and solo maintainers. Several people say Drupal needs a maintenance budget that does not match a small site's value. Others say the time is manageable when the codebase follows current practices, updates happen frequently, and automated tests catch regressions. Both can be true because the module mix and operating discipline change the workload dramatically.

Learning curve is another recurring theme. Developers coming from WordPress may understand PHP and theming but still need time for entities, Views, configuration management, services, permissions, render arrays, and Drupal's conventions. The system becomes productive after that mental model clicks. Until then, apparently small changes can feel like the CMS is hiding the steering wheel.

I treat these comments as risk discovery. Before buying, I ask who applies patches, what happens when a contributed module lags a major version, how deployment and rollback work, and whether the organization can replace a departing Drupal specialist. Those questions tell me more than a feature checklist.

I do not evaluate Drupal with a homepage and three blog posts. That proves installation, not fit. I take one awkward content family from the real organization and include relationships, roles, moderation, media, search, multilingual fields, and a frontend requirement that is likely to expose architectural shortcuts.

Editors should perform the trial without a developer narrating every click. Developers should perform a core or module update, deploy configuration, restore data, and inspect logs. The buyer should price three years of ownership, not the first sprint. If the proof of concept avoids daily work and maintenance, it has been designed to win rather than designed to inform.

I choose Drupal when the complexity in the prototype belongs to the organization and Drupal helps organize it. I walk away when most of the complexity belongs to Drupal itself and the organization only needed a good-looking, easily maintained website.