503 error: what it is, how to fix it and what Google does

A 503 error (service unavailable) is the response a server sends when it is alive but cannot attend to you right now, and this week it came back into the conversation for a very concrete reason. On October 21, PHP released emergency patches for two critical flaws, many teams took their sites down to apply them, and that same day Google Search Central reminded them on LinkedIn to respond with a 503 while they work. John Mueller, from Google, was more direct on Bluesky: use 503 instead of letting responses time out, return 404 or return 500.

I like that Google said it out loud, because it is one of those details that gets decided at 11 p.m., with the site down and someone asking "so what do we put up in the meantime?".

My take is that the 503 error is the only status code that asks Google to come back later, and on a large site it is worth using it on purpose in every maintenance window and watching for the one nobody planned, because a 503 on robots.txt or in a CDN rule can stall crawling of the whole site even while people see it working perfectly. Here is what it means, what causes it, how to fix the 503 error and what Google does when it finds one.

What is a 503 error?

The 503 error (503 Service Unavailable, or "service unavailable") is an HTTP status code from the 5xx family, the server errors. It says something quite specific: the server exists and received your request, but it cannot process it right now, usually because it is overloaded or under maintenance. By definition, it is a temporary condition.

The analogy that works best for me is the "back in 15 minutes" sign on a shop door. The shop is still there, the address is right and nobody closed the business. There is just nobody at the counter right now. A 404, on the other hand, is reaching the address and finding an empty lot.

The message you see changes with the server and its configuration: "Error 503", "HTTP Error 503", "503 Service Unavailable", "Service unavailable" or a maintenance page with the brand's logo. Google does not care about the design of that page. Google reads the status code the server returns and uses it to decide what to do with your URLs.

What causes a 503 error?

The causes repeat from site to site:

• Too much traffic. More requests arrive than the server can handle with its CPU, memory and connections. A classic is the campaign that worked too well: in 2017 Renfe's website collapsed when it offered 25-euro train tickets for its anniversary.

• Maintenance or updates. Backups, version changes, security patches like this week's PHP ones. During that window the service is down on purpose.

• Plugins and themes. In WordPress, an incompatible plugin or a badly coded theme can push resource usage until the site falls over.

• Server configuration. PHP memory limits set too low, a misconfigured load balancer or processes that got stuck.

• Firewall and bot protection. Rules that are too strict or a request limit that blocks legitimate requests and answers with a 503.

• DDoS attacks. An attack that floods the server with requests until it has no capacity left for real visits.

• Database and third-party services. A slow database, an API that is down or a payment gateway that does not respond can leave the page without the data it needs to load.

Sometimes the 503 error is intermittent: it comes and goes. That usually happens when load goes up and down (a traffic peak, a bot requesting pages at full speed) and the underlying problem is still there. If it fixes itself after ten minutes, that is a truce: if nobody touches the root cause, it happens again at the next peak.

There is one source that guides rarely mention and that, on large sites, I find the sneakiest: the 503 that only bots see. The CDN or the firewall decides that Googlebot is making too many requests, serves a 503 to it and nobody else, and the team never notices because the site loads fine from the office.

What should you do if you see a 503 error on someone else's site?

If the 503 error shows up on a site that is not yours, there is little you can do. Reload the page after a few seconds, wait a few minutes if it looks like maintenance and come back later. Switching browsers will not help, because the problem is on the server side.

How do you fix a 503 error on your site?

If the site is yours, before touching anything answer two questions: since when is it happening and who is it happening to (every URL or one template, people or only bots). With that clear, this is the order I would follow to fix the error:

1. Check whether maintenance is under way. Look at your hosting control panel, your provider's and CDN's status pages, and any notice emails. If someone is applying a patch, the 503 is the expected behavior.

2. Read the logs. The Apache or NGINX error file, and debug.log if you use WordPress, usually tell you which script, query or process failed and when. Look for repeated messages around the time the problem started.

3. Check resource usage in your hosting. CPU, memory and I/O maxed out almost always point to traffic, a heavy process or an extension eating up the server.

4. Restart the services. The web server, PHP or the database may have stuck processes. Restarting frees capacity, although it does not explain what happened.

5. Deactivate plugins and switch to the default theme. Turn them all off at once and, if the site comes back, reactivate them one by one until you find the culprit. Without panel access, rename their folder over FTP.

6. Review the firewall and the CDN. Confirm that no new rule is blocking legitimate IPs, including Googlebot's.

7. Scale up or ask for support. If real traffic exceeded what your hosting can give, it is time to move up a plan or change architecture. And if none of the above works, write to your hosting support with the exact time of the problem and what you already tried.

How is a 503 error different from a 500, 502, 504 or 429?

They look alike on screen, but they tell the browser and Google different things:

All 5xx codes end up in the same drawer for Google, according to its documentation on status codes. What makes the 503 useful is what it communicates: it explicitly says "come back later", and this week Mueller endorsed a pretty useful order of preference for an outage: 503, then 500, then 403, then 404 and, at the very end, a 200 with an error page.

Does a 503 error affect SEO?

It depends on how long it lasts and where it shows up. A 503 error of a few minutes carries no weight: Gary Illyes, from Google, said in 2024 that a 503 of 10 to 15 minutes every now and then is not "extended" by any means. The risk shows up when it stretches into hours or days.

This is what Google documents about server errors:

• Googlebot temporarily slows down crawling when it gets 5xx or 429 responses, and gradually speeds back up once the server responds normally. The slowdown is proportional to the number of URLs returning errors.

• URLs already in the index are preserved, but if they keep returning errors they eventually get dropped. Google does not give an exact timeframe.

• While a page returns a 503, Google cannot refresh its title, description or structured data.

• For an urgent pause of one or two days, Google's guide to pausing a site recommends the 503. For longer closures, it suggests keeping an indexable page that returns 200.

In other words, the question for your team is how many hours and on which URLs. A one-hour maintenance with a 503 is invisible to SEO. A store that returns 503 to Googlebot for three weeks because the CDN mistook it for an aggressive bot is a different story.

One more detail: Google documents 503 or 429 as a way to slow down crawling when Googlebot overloads the server, but recommends not doing it for long, because it delays the discovery of new pages and the refresh of existing ones (for context, the article on crawl budget covers when crawling is worth worrying about).

What happens if robots.txt returns a 503 error?

This is the part of the article I care about most. According to Google's specification, if robots.txt responds with a 5xx, Google stops crawling the whole site for the first 12 hours while it keeps trying to read the file. If it cannot, it uses the last good version it has cached for up to 30 days.

Translated: a maintenance mode that returns 503 for every URL, robots.txt included, switches off crawling for the entire site. That is why Google's guide explicitly says not to return a 503 for robots.txt. We also covered it in the robots.txt guide: the shortest file on the site can stall everything else.

How do you run maintenance with a 503 error without losing rankings?

If you are taking the site down on purpose (for a patch, a migration or a server change), these are the steps I would leave written in the checklist:

1. Serve the 503 from outside the application. If the problem is PHP, the 503 cannot depend on PHP. Mueller suggested answering it from outside PHP, from the CDN or by pointing DNS elsewhere.

2. Keep robots.txt returning 200. It is a static file, so it can be served separately even when everything else is down.

3. Add the Retry-After header. It comes from the HTTP standard and tells browsers and bots when to try again, in seconds or as a date. It adds context, although Google does not promise to return at exactly that time.

4. Check the CDN configuration so it does not cache the 503. If the error response gets cached, users and bots can keep receiving it after the site is back.

5. Avoid shortcuts. No error pages with a 200 code (Google may index the error message), no mass 404s, no temporary noindex and no Search Console removals tool.

6. If it will last more than a couple of days, change strategy. Keep an indexable home page with a 200 code that explains the situation, as Google suggests for long closures.

7. When you are back, check. Inspect your best-selling pages in Search Console and confirm they return 200.

Migrations are my favorite source of these accidents, because they combine rush, a staging environment and a new server. The checklist for redesigning your website has the rest of what I would review.

How do you know whether Google is seeing 503 errors?

Here is the difference between the 503 you see and the one Google sees. For the second one there are two sources:

1. Search Console, under Settings > Crawl stats. The breakdown by response shows what share of Googlebot's requests ended in a server error (5xx), and host status shows whether there were problems reading robots.txt or connecting to the server. If you see a jump there and nobody announced maintenance, it is worth investigating.

2. Server logs. This is the method we use in enterprise site audits: we take 30 days of logs, filter real Googlebot visits (verified, not anyone claiming the name) and group errors by template: product pages, categories, filters, internal search. A 503 scattered at random is usually load. A 503 concentrated in one template is usually a slow database query or a firewall rule.

An illustrative example: a site with 400,000 Googlebot requests a month where 6% end in 503, almost all on category pages between 9 and 11 a.m. That pattern already tells you where to look (and it may match the time marketing launches its campaigns). If you also want to check the indexing status of the affected pages, how to index a page on Google covers each status.

How do you keep the server from returning a 503 error again?

Prevention is less glamorous, but it saves nights:

• Monitor availability and resources with alerts, so you find out before your customers do.

• Load test before the peaks. If you know a sales event or a big campaign is coming, simulate that traffic in a staging environment before the day. If your peak is Black Friday, Black Friday SEO has the data on when the clicks arrive.

• Use caching and a CDN so the origin server works less on every visit.

• Keep the CMS, plugins and theme updated, and test each update in staging before publishing it.

• Plan maintenance for low-traffic hours, with the 503 and robots.txt configured as in the previous section. If your hosting plan falls short every time there is a campaign, that conversation belongs here too.

• Review bot rules in the CDN and firewall every time someone from security changes them, with SEO in the conversation.

What I would check this week

If your team applied the PHP patches or has a maintenance window scheduled, open Search Console and look at Crawl stats for the last seven days: if there is a jump in server errors, cross-check the date with the maintenance window. Then run a curl -I on your robots.txt during the next scheduled maintenance and confirm it returns 200. It takes ten minutes and it is a lot cheaper than finding out through a drop in the November report.