How to Take a PHP Website Offline Without Stopping Your Business
Taking a PHP website offline without stopping the business behind it means separating two different problems that most teams handle as one: how the site itself goes down (a 503 status code, not a silent failure or a 200 that quietly tells search engines the broken page is the real one), and where customers go to keep buying and getting support while it is down, which should never depend on the same infrastructure that just failed.
Taking a website offline safely means returning a 503 status code rather than a 200, 404, or a blank error page, so search engines treat the downtime as temporary rather than as the page actually changing or disappearing, while business continuity means routing customers to a working payment, support, and communication channel that sits on entirely separate infrastructure for the duration.
- Taking a site offline the wrong way (returning a 200 or 404 during downtime) can get URLs dropped from the index; Google's own guidance recommends a 503 status code with an optional Retry-After header instead.
- Keep robots.txt itself reachable during downtime: a 5xx there specifically can make Google halt crawling for up to 12 hours before it falls back to a cached copy for as long as 30 days.
- A maintenance page alone does not contain an active hack: an attacker with an existing web shell, database connection, or valid session token keeps that access until the database connections are terminated, sessions invalidated, and the server or container isolated.
- Preserve logs and evidence before cleaning anything up if the downtime is incident-driven, and change every credential (hosting, database, CMS admin, associated email) as part of recovery, not just the one that was obviously compromised.
- A status page hosted on separate infrastructure and a different domain stays reachable precisely when the main site cannot, and should state the impact on customers first, not just technical detail.
- Business does not have to stop with the site: a hosted payment link, a WhatsApp Business line, and an updated Google Business Profile message can keep orders and support running on infrastructure the outage never touches.
Why does it matter how a site is taken offline, not just that it is?
Google's own guidance on planned downtime recommends returning a 503 (Service Unavailable) status code rather than a 200 or a 404 during the outage, with an optional Retry-After header specifying how long the downtime is expected to last. A 503 signals temporary unavailability; a 200 on a broken or blank page risks that page being indexed as the site's real content, and a 404 signals the page is simply gone, which can trigger de-indexing that then has to be reversed once the site returns.
Duration matters too: a 503 left in place for more than roughly a day or two risks URLs being dropped regardless of the status code being technically correct, since prolonged unavailability eventually reads as real unavailability rather than planned maintenance. robots.txt is a special case worth knowing on its own: a 5xx response specifically on that one file can make Google halt crawling of the whole site for up to 12 hours, then fall back to a cached copy of robots.txt for as long as 30 days, so keeping that one file reachable during maintenance is worth checking explicitly rather than assuming it inherits the same maintenance page as everything else.
How do you actually take a PHP site offline the right way?
For planned maintenance, the cleanest approach is a small PHP check near the top of the application's entry point (or a web-server-level rule in Apache or Nginx) that, when a maintenance flag is present, immediately sends a 503 header and an HTML maintenance page, then exits before any further application code runs. This avoids partially executing a broken application and keeps the response fast rather than timing out. At the web-server level, the rule can run before PHP is ever invoked, which is both faster and safer than handling it inside the application:
location / {
# Serve the static maintenance page with a real 503 status
# whenever maintenance.flag exists, instead of hitting PHP-FPM.
if (-f $document_root/maintenance.flag) {
return 503;
}
try_files $uri $uri/ /index.php?$query_string;
}
error_page 503 @maintenance;
location @maintenance {
rewrite ^(.*)$ /maintenance.html break;
}Is a maintenance page enough to contain an active hack?
No, not on its own. If a hack or remote code execution is suspected, routing traffic to a maintenance page only stops new visitors from reaching the compromised application; it does nothing about an attacker who already has an active web shell, an open database connection, or a valid session token from before the block went up. A maintenance page changes what the public sees, not what the attacker can still do on the server behind it.
Real containment means cutting the attacker's access, not just the public's: terminate active database connections and rotate the database credentials they were using, invalidate all existing session tokens so a stolen or forged session cookie stops working immediately, and isolate the affected server or container from the rest of the network (removing it from a load balancer, revoking its outbound network access, or suspending the container) before relying on the maintenance page to hold the front door. Only once those are done does the maintenance page actually reflect the server's real state, rather than papering over continued attacker access underneath it.
What's the right incident-response sequence after containment?
Once the site is no longer publicly reachable and the attacker's access has actually been cut, preserve evidence before cleaning anything up: a full backup of the server, including web, FTP, SSH, database, and system logs, so there is a record of what actually happened rather than only a guess after the fact. Only then move to recovery: rotate every credential tied to the domain (hosting account, FTP/SFTP, database, CMS admin accounts, and the email addresses associated with the domain, since a compromised inbox can be used to reset everything else), identify and fix the actual entry point, and, where practical, redeploy the fixed version to a clean OS and web server setup rather than only cleaning the existing one in place.
How do you keep customers informed while the site is down?
Host the status update somewhere the outage cannot reach: a separate domain and separate infrastructure from the main site, whether that is a dedicated status-page tool or just a static page hosted elsewhere entirely. A status page that lives on the same server as the thing that just went down is not a status page, it is one more thing that can fail at the same time.
Write the update for what customers actually care about first: the impact on them (can they still place an order, reach support, access their account), not a technical description of what broke. If there is a workaround, state it directly rather than leaving customers to guess. Offer a way to get updates without needing to keep refreshing: email, SMS, or a messaging channel, and post a clear resolution message once service is restored rather than letting the last update quietly go stale.
How does a business keep operating while the website is offline?
Payments do not need the main application to keep working. A hosted checkout page from the existing payment processor, for example a Stripe Payment Link or a Razorpay Payment Page, can take orders and process payments on the processor's own infrastructure, entirely independent of whatever is broken on the PHP site, and can be shared directly through social media, email, or a status page link in the meantime.
For support and ongoing sales conversations, WhatsApp Business is a workable stopgap: a product catalog customers can browse and order from in chat, even without the automatic cart-and-total calculation a full checkout provides, kept open by someone actively monitoring messages during business hours rather than left unattended. A Google Business Profile listing can carry an updated post or messaging option pointing customers to the temporary channel, and existing social accounts and an email blast to the customer list cover the rest of the announcement.
None of this needs to be built during the incident. The payment link, the WhatsApp Business catalog, and the Google Business Profile messaging option all take minutes to set up in advance and then sit idle until needed, which is the entire point: the cost of having them ready is near zero, and the cost of not having them when the main site goes down is every sale and support request that silently disappears during the outage.