Does site maintenance hurt your Google rankings?

In October 2026, two critical PHP (Hypertext Preprocessor, the language that powers a large share of the web) flaws, recorded as CVE-2026-109618 and CVE-2026-109619, forced teams worldwide to patch servers in a hurry. CVE (Common Vulnerabilities and Exposures) is the public registry that gives every known security flaw a name and a number. Many of those teams took the site offline to apply the fix.

The technical decision was right. The execution, in a good share of cases, cost search rankings.

That is where site maintenance stops being a technology matter and becomes a marketing one. Infrastructure applies the patch, but it is enrollment that loses applicants when the blog disappears from Google.

The difference between a harmless pause and an expensive one comes down to three decisions: which status code the server returns, what happens to one specific file at the root of the site, and how many days the situation lasts.

What is site maintenance and when is it necessary?

A site in maintenance is a site that already exists, is already known to search engines and becomes temporarily unavailable because of a technical intervention. The difference from a site under construction is essential: the second one was never live, has no history to preserve and risks losing nothing.

Caption: site maintenance handled badly dissolves, piece by piece, the presence the site already had in Google results

That distinction changes the technical answer completely. On a site under construction, blocking crawling is acceptable, because there is no earned position at stake. On a site in maintenance, the same block throws away years of work.

The situations that most often push education teams into a planned pause are predictable. An urgent security update, a server or hosting change, a database repair and the launch of a major site redesign.

One of those situations has rules of its own and is not solved with the same precautions. Changing the site's address involves redirects and reindexing, and the procedure is detailed in how to run a domain migration without losing rankings.

Not every maintenance job requires taking the whole address offline. Swapping a template, adjusting forms or publishing new pages usually happens with the site live, and that is always the first option to consider.

It is worth separating maintenance from an outage. A planned pause has a start time and an end time, which is why it allows for preparation. Unexpected downtime belongs to another category, closer to the causes listed in an investigation of an organic traffic drop.

Does site maintenance make you lose rankings on Google?

A well-run maintenance window of a few hours usually passes with no visible effect on rankings, including for pages sitting on the first page of Google. The risk is not the site going offline, but what the server answers while it is down and how long the situation lasts.

Those two variables are what separate a neutral incident from a real loss. Every decision about the pause comes down to getting both right.

The mechanism is straightforward. Googlebot visits the page, receives a response and decides what to do with that URL (Uniform Resource Locator, the address of a page on the web) based on it. A response that says “come back later” preserves the record. A response that says “this no longer exists” authorizes removal.

When removal happens, the damage is not one page's position. It is leaving the index, and Google warns that there is no fixed time for recovery from a complete removal, which can take quite a while and has no mechanism to speed it up.

There is also a quiet effect that shows up even in a short pause. While a URL responds with temporary unavailability, Google cannot update that page's title, description, metadata or structured data.

For an institutional site that has just published its admissions calendar, that means the SERP (Search Engine Results Page, the page of search results) may keep showing the old information for longer than expected. The new content is on the server, but the storefront still shows the previous version.

There is also the path nobody chooses but plenty of teams stumble into. It is the recipe for making a site lose its Google rankings: take everything down, return a generic error and leave it that way for a few weeks.

People studying how to rank on Google rarely think about availability, and that is exactly where the risk lives. No amount of content or authority work survives a page the crawler cannot open.

Video: the SEO fronts that site maintenance puts at risk when the pause is mishandled, on the mkt4edu channel (in Portuguese)

Which status code for site maintenance: 503, 404 or 500?

The right code for a site in maintenance is 503, which signals temporary service unavailability in HTTP (HyperText Transfer Protocol, the protocol that serves web pages). Google's John Mueller recommended exactly that on 21 October 2026 for the sites taken offline during the emergency PHP fix, instead of letting responses time out, fall into 404 or return 500.

The recommendation came with a practical detail that helps whoever does not control the application server. The 503 can be returned outside PHP, by pointing the DNS (Domain Name System, which translates the site's address into a server) somewhere else or by configuring the response on the CDN (Content Delivery Network, the network that distributes the site's content).

At many institutions, the application being down is precisely the reason for the unavailability. Without that option outside PHP, the team would have no way to return anything at all.

Three responses do damage and show up often in improvised pauses. Here is what each one tells the crawler:

• 404 or 410. They say the page no longer exists. Google documents that blocking the site with 403, 404 or 410 removes the site's URLs from Search.
• 500. It signals a generic server failure, with no information that the situation is temporary and has an expected end.
• Timeout. This was one of the exact responses the recommendation asked teams to avoid, because the request drags on and the crawler walks away with no useful information about the state of the site.

A fourth trap is the noindex tag on the maintenance page. It looks like the cautious choice, but it produces the same result as the removal codes: the URLs leave search.

Two more precautions complete the setup. The first is sending the Retry-After header with an honest estimate of when the site returns, advice that comes from Google's own guidance on pausing an online business and helps the crawler schedule its next visit.

The second is keeping the maintenance page static and light. An error page that depends on the database you just took down will not load, and then the server ends up returning the very timeout you were trying to avoid.

Why can't robots.txt return 503 during maintenance?

Robots.txt has to keep answering normally during maintenance, because Google states that a 503 on that file blocks all crawling. It is the most expensive mistake on the list, and also the easiest to make without noticing, since it comes from a setup that looks correct.

The road to the mistake is usually the same. The team decides to apply the 503 and sets the rule in the CDN panel, broadly, for the whole domain. The rule catches the entire site, and robots.txt comes along with it.

The result lands far from the original intent. Crawling stops completely, not only on the pages that were actually offline.

The opposite extreme does equal damage. Publishing a valid robots.txt that disallows all crawling during the pause may remove the site's content and URLs from search, which is the exact opposite of the intent.

The correct setup is less intuitive than it sounds. Robots.txt returns 200, with its usual content, while every other URL returns 503. Those are two different behaviors inside the same domain, and that has to be written into the ticket that goes to the technical team.

Each type of block shows a distinct symptom in the reports, and recognizing the difference speeds up the diagnosis. That mapping between blocking layer and symptom is detailed in the article on how to validate Googlebot crawling.

How long can a site stay in maintenance?

A few days at most. Google treats disabling the whole website as an extreme measure and recommends keeping the site online with limited functionality whenever possible. When a full shutdown is unavoidable, the same guidance says it should last a very short period, a few days at most.

The first alternative is not always taking the site down. Turning off only the function that requires the intervention and keeping the rest browsable preserves visibility and solves a good share of cases.

For an education institution, that is more feasible than it sounds. You can suspend the application form while keeping course pages, the blog and contact information live, and those are precisely the ones holding up organic presence.

When the pause has to run beyond a few days, the technical answer changes. Instead of keeping everything on 503, the guidance is to serve an indexable home page, with a 200 status code, explaining the situation.

The logic of the swap is simple. A page returning 200 is still a valid page in the search engine's eyes, while site maintenance that piles up weeks of 503 keeps adding removal risk.

Here is how the three duration bands work out in practice:

Table: recommended technical response for site maintenance, according to the expected length of the downtime

One operational consequence goes unnoticed and gets in the way of exactly the people who need to track the damage. Google warns that, during the pause, Search Console property verification fails, which can cut off access to the reports at the worst possible moment.

Does site maintenance affect citations in AI answers?

Generally yes, and through the same path as traditional search. Google's AI (Artificial Intelligence) experiences live inside Search and are fed by Googlebot, so a site that blocks crawling tends to lose presence in generated answers too. Assistants from other companies run into the same 503, with their own crawlers.

One limit should be stated plainly. Google documents the effect of unavailability on indexing, not on generated answers specifically, so this reading is a consequence of the known mechanism, not a published behavior.

There is a vocabulary difference that muddles internal conversations. What many teams call ranking in AI is really citation: in generated answers there is no numbered position to lose, there is a mention that stops happening, an effect that is harder to measure and slower to notice.

That changes how you track the damage. A ranking drop shows up in any rank tracker the next day, while a missing citation only surfaces for teams already monitoring brand mentions in answers, a practice that belongs to a structured SEO for AI strategy.

There is an important mitigating factor for anyone who went through a short pause. Because the factors that weigh most to rank in AI are content and authority rather than momentary availability, they stay intact once the site is back.

How do you recover organic traffic after maintenance?

Recovery starts by confirming that the whole site is back in Google, not just the front door. After a well-run pause, organic traffic tends to settle on its own as crawling picks up its rhythm. After a mishandled one, the comeback depends on reindexing, and there is no guaranteed timeline.

The first step is checking what the server is returning right now. It is worth testing the home page, a course page, a blog post and robots.txt, because the maintenance rule often stays behind on some specific path.

The second step happens in Search Console. URL inspection shows how Google is seeing each address at the moment, and the pages report reveals whether anything was marked as not found during the downtime window.

The third step is asking for crawling back, with judgment. For a handful of pages, the individual request does the job, and for many, the path is the sitemap, a practice that also appears in the routines described in the article on how Google Search Console works.

The fourth step is watching rankings for a few weeks without reacting to day one. Fluctuation right after the comeback is expected, and checking your site's position on Google across a series of days avoids decisions made on noise.

One final precaution avoids the wrong diagnosis. If the drop does not recover within a few weeks, the cause may not be the maintenance at all, and it is worth running the full investigation before blaming the pause.

Video: the checklist that helps you review every page once site maintenance is over, on the mkt4edu channel (in Portuguese)

Frequently asked questions about site maintenance

Where to start before the next site pause?

The next maintenance window on your institution's website will happen, with or without warning, and whether it comes out cheap or expensive is agreed before, not during. The whole set fits into four requests to the technical team: 503 on every URL, Retry-After with a real estimate, robots.txt returning 200 and a static maintenance page.

Those four items fit on half a page, attached to the shutdown procedure. It is a one-hour investment that protects years of building authority and organic positioning.

People studying how to improve a site's SEO usually start with content and speed, and rarely with availability. Protecting what already exists costs less than winning back lost rankings.

Agree as well on who checks what after the comeback. With no owner assigned, verifying robots.txt and running URL inspection gets pushed to later, and the problem only surfaces once traffic has already dropped.

With the procedure agreed, the next question stops being the pause and becomes the index. What decides whether a page enters or leaves it is covered in why a post does not show up in Google indexing.