Drupal's maintenance mode shows visitors a deliberate, branded "Site under maintenance" message while logged-in administrators can still browse normally. An unreachable server shows a browser-level or host-level error — a timeout, a 502, or a blank connection failure — because nothing is answering at all. The difference matters because one is a controlled, recoverable state the site owner chose, and the other is a failure the site owner may not even know about yet. Knowing which one a visitor sees tells you whether to check your to-do list or check your hosting panel.
Table of Contents
- What Drupal's maintenance mode actually does
- What an unreachable server looks like instead
- How to tell which one you're looking at
- What each situation means for visitors and search engines
- What a site owner can do in each case
What Drupal's maintenance mode actually does
Maintenance mode is a built-in Drupal feature, toggled from Configuration > Development > Maintenance mode, or by setting `$config['system.maintenance_mode'] = TRUE` in settings.php. When it's on, Drupal itself is still running — PHP is executing, the database connection is alive, and the web server is answering requests normally. What changes is the response Drupal sends to anonymous visitors.
Instead of rendering the requested page, Drupal serves a simple maintenance page, usually with the text "Site under maintenance" or a custom message the administrator wrote in the same settings screen. The HTTP status code for this page is typically 503 Service Unavailable, which correctly tells browsers and search engines the content is temporarily unavailable rather than gone. Users with the "bypass maintenance mode" permission — normally administrators — can log in and use the site exactly as before, including the admin toolbar and content editing screens. This is the core purpose of the feature: let a developer or site owner run updates, database changes, or module installs without a mix of visitors hitting half-updated code.
What an unreachable server looks like instead
An unreachable server is not a message from Drupal at all, because Drupal never gets the chance to run. The failure happens earlier in the chain — at the network, DNS, web server, or hosting level — before any PHP code executes.
Visitors typically see one of a handful of browser-generated or infrastructure-generated errors: None of these pages come from Drupal's theme or templates, because Drupal's code was never reached. There is no "bypass" for an administrator in this state — a logged-in admin sees the exact same failure as everyone else, since the problem sits below the application layer entirely.
- A browser timeout page ("This site can't be reached") when the server doesn't respond at all.
- A 502 Bad Gateway or 504 Gateway Timeout from a reverse proxy or load balancer in front of the actual web server.
- A 500 Internal Server Error from the web server itself, often when PHP has crashed or a configuration file is broken.
- A DNS error when the domain no longer resolves to a working server address.
How to tell which one you're looking at
The fastest check is whether the page looks like it came from the site at all. A Drupal maintenance page usually keeps the site's branding, theme, and layout, because it's rendered through the same theme system as every other page — just with a different message in place of content. An unreachable-server error almost never carries site branding. It's either a plain browser error screen, a generic server error page from the hosting provider or CDN, or a bare error string with no styling.
If the page has no logo, no navigation, and no familiar colors, the problem is almost certainly outside Drupal's control. A second check, for anyone with admin access, is simply logging in. If logging in restores normal site access while maintenance messaging disappears, Drupal was deliberately in maintenance mode. If logging in is impossible because the login page itself won't load, the server is the problem, not a Drupal setting.
- Branded message, consistent theme, 503 status → Drupal maintenance mode.
- Generic browser or host error, no branding, 500/502/504 or timeout → server or infrastructure issue.
- Admin login works and clears the message → maintenance mode.
- Admin login page itself fails to load → server unreachable.
What each situation means for visitors and search engines
For visitors, maintenance mode is a signal to come back later — the site owner is actively working on something and expects to finish soon. An unreachable server gives no such signal; visitors have no way to know whether the issue will resolve in minutes or persist for days, because nobody designed that error page to communicate anything beyond failure. For search engines, the distinction has practical consequences.
A correctly configured maintenance page returning a 503 status tells crawlers the unavailability is temporary, so they typically continue to treat the page as indexed and retry later rather than dropping it from results. A server that returns repeated 500 errors, or that simply times out, risks being treated as a persistent failure if the outage lasts long enough, which can affect how quickly the site recovers in search results once it's back. This is also why leaving a site in maintenance mode for an extended period is different from an actual outage in terms of risk: maintenance mode is still a functioning server making a deliberate choice, while an unreachable server offers no such assurance to crawlers or visitors.
What a site owner can do in each case
If maintenance mode is intentional, the main task is making sure it doesn't run longer than needed and that the message tells visitors something useful, since the default text is minimal. Checking that admin bypass still works before stepping away confirms the toggle was applied correctly. If the server is unreachable, the troubleshooting path is different, because the problem sits outside Drupal entirely: Because an unreachable server bypasses Drupal's own permissions and bypass rules, admin credentials alone won't resolve it — the fix has to happen at the hosting or network level before Drupal can run again.
- Check whether the hosting account or server instance is running, since billing or resource limits can take a server offline without warning.
- Check DNS settings if the domain isn't resolving, particularly after a provider change.
- Check web server and PHP error logs directly on the server, since Drupal's own logs won't capture a failure that happens before Drupal loads.
- Contact the hosting provider if the server itself appears down, since that layer is outside the site owner's direct control.
