Your website opens for you, but Google Search Console reports Server error (5xx). Start with two checks: whether customers can use the affected pages now, and whether the failure that interrupted Google’s visit has actually stopped.
The commercial priority is a working website. A service page that intermittently fails deserves attention even before you see a change in search traffic. Equally, an old outage should not trigger an unnecessary rebuild or hosting move. Establish what failed, when it happened and what evidence shows recovery.
What does Server error (5xx) mean?
Google’s Page indexing documentation says this label means the server returned a 500-level error when Google requested the page. The label identifies an access problem; it does not identify which component needs repairing.
According to Google’s HTTP status-code guidance, 5xx responses and 429 responses can make its crawlers slow down. Already indexed URLs may remain initially, but persistent server errors can eventually cause their removal. Once successful responses resume, crawling increases gradually. There is no universal recovery deadline.
Keep the actual response code in your notes. A 500, a 502 and a 503 should not be collapsed into “the website is slow”. Google also treats 429, Too Many Requests, as a server-overload signal, despite its different number.
1. Establish whether customers are affected now
Open an affected URL from the report, rather than checking only the homepage. Try it while signed out, then use a phone on mobile data. Follow the route a customer would take: open the service or product page, select the next step and reach the enquiry, booking or checkout screen.
Record what happens without repeatedly submitting real enquiries or payments. If the public journey is failing, give restoring that journey priority over clearing a reporting label.
Use the pattern to scope the investigation:
- One page fails: ask your developer to start with that page and its specific functionality.
- One section fails: identify what the affected pages share, such as a template or integration.
- Unrelated pages fail: ask your host to investigate the wider serving infrastructure.
- Everything works now: retain the reported crawl dates and investigate whether the incident was temporary or recurring.
These are starting points for investigation. A working homepage alone is insufficient evidence to close an incident involving product pages or a quote journey.
2. Compare the recorded crawl with a live test
Inspect a reported URL in Search Console. Note its last crawl date and the recorded page-fetch result. Then select Test live URL to check current access.
Google’s URL Inspection guidance distinguishes the stored indexing information from the live test. A live test can succeed after an earlier server failure, and a successful result does not guarantee indexing.
Keep those findings separate in your handover: “Google’s recorded crawl failed on this date; today’s live test succeeded at this time.” That is more useful than saying Search Console is wrong.
Ask your developer to inspect the returned content as well as the response. A page should show the intended service, product or information. Google’s status-code guidance explains that a success response containing an empty page or error message can produce a soft 404. Merely replacing the error code with 200 is not a repair.
If failures appear intermittent, choose a small set of important affected pages and repeat checks at agreed intervals. Include the periods associated with the original failures. Avoid hammering the site with a large automated crawl during an unresolved availability problem.
3. Use Crawl Stats when you need wider evidence
For a recurring or widespread problem, ask your technical team to review Settings > Crawl stats. Google’s Crawl Stats documentation describes host availability, response types and example requests. The report is available for root-level properties; its example URLs are not a complete log.
Compare the error dates with host status and response-time changes. Check whether the availability issue concerns server connectivity, DNS resolution or fetching robots.txt. Give the relevant findings to the person responsible for that part of the website.
For a small site with a single resolved incident, this may be work for your host rather than another dashboard for you to monitor. Google’s separate crawl-budget guidance focuses on large or frequently updated websites. A typical business site should not turn a confirmed server fault into a speculative crawl-budget project.
Build a short incident timeline alongside the technical evidence. Include releases, plugin updates, imports, scheduled processing and supplier incidents that occurred near the failures. A matching time is a lead to investigate, not proof that the change caused the error.
4. Give your host a useful investigation brief
Send a compact evidence pack instead of “Google cannot see our website”. Include:
- The exact affected URLs, including any query strings needed to reproduce the problem.
- The reported error and any more specific response code observed.
- The date, time and time zone of failures and successful retests.
- Whether customers are affected and which commercial journeys are interrupted.
- The relevant Search Console findings and a screenshot of any visible error.
- Recent changes that your team should compare with the incident.
If the website uses Cloudflare, its 5xx troubleshooting guidance specifically asks for the code, URL, time and time zone. It also warns that the explanation may lie in logs from intermediate systems, rather than only the origin server.
Ask the host and developer to agree who owns the investigation. Request a finding that explains which part failed, what evidence supports the diagnosis and what will be changed. “It loaded when we checked” is a useful observation, but leaves an intermittent fault unresolved.
Google’s Page indexing guidance includes hosting capacity, configuration and unintended blocking among the areas to investigate. Ask for evidence before approving a hosting upgrade or a broad configuration change. Avoid making several unrelated changes together: agree a focused repair and a way to establish whether it worked.
Keep the repair proportionate
For a shop, agree how orders placed during the investigation will be preserved. For a service business, establish how the team will check for interrupted enquiries. If a rollback is proposed, make sure the plan accounts for information received since the restore point.
Include the necessary specialist. Web development support is relevant when the failure follows a particular feature or release; hosting support is relevant when the evidence points to serving infrastructure. Clear responsibility helps prevent the incident being passed between suppliers.
5. Verify recovery before validating the fix
Agree acceptance checks before closing the work. Our recommended minimum is:
- Page access: the affected public URLs consistently return their intended content.
- Customer completion: a controlled enquiry, booking or order reaches its expected destination without unwanted duplicates.
- Current Google access: live inspection succeeds for a representative set of affected pages.
- Recurrence: monitoring covers the period or activity associated with the original failure.
- Ownership: someone is responsible for responding if the fault returns.
Once the underlying issue is resolved, use Validate fix in the Page indexing issue details. Google’s validation guidance says to fix all instances first and let the current validation attempt finish before starting another. Validation can take longer than the repair itself.
Keep checking important URLs individually. Google can treat an issue as resolved when a URL is no longer available, so a cleared error alone does not prove that a wanted page is accessible and indexed.
Review search visibility separately after recovery. Record the repair date and follow the affected pages’ indexing, impressions and clicks. Do not promise that clearing a server error will restore a particular ranking or number of enquiries.
Make availability part of ongoing website care
Keep the incident record brief: affected journeys, confirmed cause, repair, evidence and named owner. Use it to decide what monitoring or release checks need improving. The aim is to catch a repeat failure while the evidence is still available and give the next investigation a clear starting point.
If Search Console keeps reporting server errors and your suppliers cannot explain them, talk to BuzzBoost about investigating the fault. We can help connect the website investigation with technical SEO priorities, so the work focuses on pages and journeys that matter to your business.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
