Website Fault and Error Pages: How to Find and Fix 5xx, 404 and Server Faults
Every website breaks sometimes. A plugin update goes wrong, a server runs out of memory, a page is deleted without a redirect, or a hosting provider has a bad afternoon. What matters is how quickly you notice the fault and how well your site handles it while you fix it. Many owners only find out when a customer complains, and by then the damage to trust, leads and search visibility has already started.
The phrase inurl:fault is a good starting point for this topic because it points at a real habit: people search for URLs that contain the word fault, error or similar terms to see how a site or a set of sites exposes problems. In this guide you will learn what that search operator does, why it should be used carefully, and how to run a far more reliable audit of your own error pages. Then we go through every common website fault, from 404 and soft 404 errors to 500, 502, 503 and 504 server errors, with a repeatable workflow to diagnose and fix each one.
What inurl:fault Means and Why Website Fault Pages Matter
The inurl: operator is a Google search operator that asks the search engine to return pages whose address contains a given word. So inurl:fault asks for pages with the word fault somewhere in the URL. On a company website, that could be a path such as an error handler, a diagnostic page or a support article about faults. Across the wider web it also returns results that have nothing to do with your site, which is why it is only useful when you combine it with other operators and know what you are looking for.
A website fault is any situation where a request cannot be completed the way the visitor or the crawler expects. Some faults are visible, such as a page that says the content could not be found. Others are silent, such as a page that returns a normal success code while showing an error message. Both cost you. Visitors leave, forms are not submitted, checkout stops, and search engines waste crawl time on URLs that should not exist.
The business cost is easy to underestimate. A broken service page, a failed contact form or a slow server response during a campaign all turn paid or organic traffic into wasted spend. Treating fault pages as a routine part of site health, not an emergency you only handle when something is on fire, is one of the simplest ways to protect leads and rankings.
Website Error Status Codes: 4xx, 5xx and 3xx at a Glance
Before fixing anything, you need to read the signal correctly. Every response from a web server carries an HTTP status code. The first digit tells you which group the response belongs to. Codes starting with 4 mean the request could not be fulfilled because of something about the request or the missing resource. Codes starting with 5 mean the server failed while trying to handle a valid request. Codes starting with 3 are redirects.
| Code | Name | Who is usually at fault | Typical urgency |
|---|---|---|---|
| 301 | Moved Permanently | Site configuration, intended | Low, check for chains |
| 302 | Found (temporary redirect) | Site configuration, intended | Low, check it is really temporary |
| 403 | Forbidden | Permissions or firewall rules | Medium |
| 404 | Not Found | Missing page or broken link | Medium, high on key pages |
| 410 | Gone | Intentional removal | Low |
| 500 | Internal Server Error | Server or application code | High |
| 502 | Bad Gateway | Upstream server or proxy | High |
| 503 | Service Unavailable | Overload or maintenance | High if it lasts |
| 504 | Gateway Timeout | Slow upstream response | High |
A useful rule of thumb: if you see a 5xx code, do not waste time editing content in your CMS. Look at the server, the application layer, the database and any network services in front of your site. If you see a 4xx code on a page that should exist, look at URLs, redirects and permissions first.
How to Use inurl:fault and Search Operators to Audit Error Pages
Search operators can help you get a quick, rough picture. Combining the site: operator with inurl: and a word such as error, fault or debug lets you check whether unexpected pages from your own domain are visible in search results. For example, you can search for your domain together with inurl:fault and see whether any diagnostic or error handling URLs have been indexed.
There are three reasons to treat this as a starting point and not a full audit. First, results are inconsistent. Site owners and SEO practitioners have reported that Google operators such as inurl: return less precise results than they once did, so an empty result does not prove your site is clean. Second, search results only show pages that have already been indexed, so they miss faults that happen in real time. Third, error output that appears in public search results can be a security concern. Pages that print stack traces, file paths, database names or software versions give attackers useful information, so if you find pages like that, remove them from public access and fix the underlying configuration.
For a dependable audit, use tools that observe your site directly: your server logs, Google Search Console, a crawler and an uptime monitor. If you want an expert review of how your site is crawled and indexed, our technical SEO audit covers exactly this kind of error and indexing health check.
404 Not Found, 410 Gone and Soft 404 Errors
A 404 error means the server is reachable but the requested page cannot be located. That is the correct response for a URL that does not exist, and Google has said that 404 responses for pages that genuinely do not exist are normal and do not by themselves hurt the rest of your site. The problem starts when 404 errors appear on pages that should exist, on URLs that used to earn traffic, or on internal links that you control.
Common causes of 404 errors include a mistyped URL, a page that was deleted, a permalink that was changed without a redirect, a broken link from another site, and a site migration that lost the permalink rules. On WordPress, a wave of 404 errors right after a migration is often fixed by re-saving the permalink settings, which rebuilds the rewrite rules.
A 410 error is more specific. It tells browsers and crawlers that the page was removed on purpose and is not coming back. In practice the difference from a 404 is small. Google may drop a 410 URL from its index somewhat faster, but if your server makes it hard to send 410 responses, a 404 is perfectly acceptable. Use 410 only for content you have permanently removed, and use 404 if the removal might be temporary.
A soft 404 is the sneaky one. The page shows a message saying the content is missing, but the server returns a normal 200 success code. Search engines may treat the URL as a real page, and Google Search Console reports these as Soft 404 issues. Soft 404s often appear when a site redirects every missing URL to the home page, or when a CMS template for an empty category returns a success code. The fix is to return a proper 404 or 410 code, or to redirect the URL to a genuinely relevant page.
| Type | Status returned | Page shows | Best action |
|---|---|---|---|
| Standard 404 | 404 | Not found message | Keep, improve the page for visitors |
| 410 Gone | 410 | Removed message | Keep for permanent removals |
| Soft 404 | 200 | Not found message | Return 404 or 410, or redirect to a relevant page |
| Redirect to home page | 301 then 200 | Home page | Avoid, treated by Google as a soft 404 style problem |
| Redirect chain to a 404 | 301 then 404 | Not found message | Remove the redirect and return the 404 directly |
To fix 404 problems properly, start with your own house. Update internal links so they point to live pages, and set a single 301 redirect from an old URL to the closest relevant new page. Do not redirect everything to the home page. If you are unsure how links pass value and where they break, our guide to broken links and hyperlinks in SEO explains the basics. When you have many URLs to review, a content audit helps you decide which pages to fix, merge, redirect or retire.
500 Internal Server Error: Causes and Fixes
A 500 Internal Server Error is the general purpose server failure. It tells you something went wrong on the server but not what. On WordPress sites the most common triggers are a plugin or theme conflict, a corrupted .htaccess file, a PHP memory limit that is too low, and damaged core files. Less often the cause is a database problem or a permissions issue after a migration.
Work through the following steps in order, and take a full backup before you change anything.
- Check the error log. Your hosting control panel or server usually stores an error log that names the file and line behind the fault. This is the fastest way to find the real cause.
- Test for a plugin or theme conflict. Rename the plugins folder using a file manager or FTP so all plugins are deactivated at once. If the site returns, rename it back and reactivate plugins one at a time until the faulty one appears.
- Reset the .htaccess file. Rename it, reload the site, and if the fault disappears, regenerate a clean file by re-saving permalinks in the dashboard.
- Raise the PHP memory limit. If the log shows an allowed memory size error, increase the limit in the configuration file or ask your host to do it.
- Restore core files. Replace WordPress core files with a fresh copy from the official package, leaving your content and configuration in place.
- Contact your host. If the fault persists after you have ruled out plugins, themes and configuration, the issue may be at server level, and the host can check resource usage, service crashes and security modules.
Plugin conflicts are among the most frequent causes, so keeping updates controlled matters. Our WordPress plugin and theme update service tests updates before they reach your live site, and if a fault has already happened, our WordPress bug fixing and troubleshooting team can trace and repair it.
502 Bad Gateway, 503 Service Unavailable and 504 Gateway Timeout
The other common 5xx errors describe problems between servers. A gateway or proxy is a server that passes your request to another server, such as a web server passing a request to PHP or a CDN passing a request to your origin. When the chain breaks, you see one of these three codes.
| Code | Plain meaning | Likely causes | First action |
|---|---|---|---|
| 502 Bad Gateway | The gateway received an invalid response from the server behind it | Stopped or crashed PHP process, upstream server down, firewall or CDN misconfiguration | Check the status of PHP and the origin server, then restart the failed service |
| 503 Service Unavailable | The server cannot handle the request right now | Traffic overload, maintenance mode, exhausted resources, a stuck maintenance file on WordPress | Check load and resources, remove a stuck maintenance file, scale or wait |
| 504 Gateway Timeout | The gateway waited too long for the server behind it | Slow database queries, heavy scripts, slow third party APIs, network problems | Find the slow process in the logs and optimise or raise timeouts carefully |
Before you touch any settings, confirm that the problem is really yours. When a large infrastructure provider or CDN has an incident, many unrelated sites show 500, 502, 503 or timeout errors at the same time. Check your hosting provider status page and the status pages of any CDN or cloud platform you use. If the outage is upstream, changing plugins or DNS records can make things worse, and most sites recover on their own once the provider fixes the issue. For a closer look at how a big cloud incident affects ordinary businesses, read our article on the AWS outage and how to protect your business.
The SEO effect of 503 responses depends on duration. A short 503 during planned maintenance is understood by search engines as temporary, and a Retry-After header can tell crawlers when to come back. A 503 that lasts for days is a different matter, because pages may eventually be dropped from the index. Repeated 502 and 504 errors usually point to resource limits or slow processing, and slow pages are a common root cause. Our piece on website speed and why it costs you clients shows how performance problems turn into visible faults during busy periods.
A Step by Step Workflow to Diagnose Any Website Fault
Whatever the status code, the same disciplined process saves time. Follow these six steps every time.
- Confirm the exact status code. Open your browser developer tools, go to the Network tab, reload the page and read the response code for the main document. Friendly error screens can hide the real code, and a page that looks like a 404 might actually return 200 or 500.
- Check upstream status. Look at your host, CDN and cloud provider status pages. If they report an incident, wait and monitor instead of making changes.
- Review recent changes. Ask what changed in the last day: a plugin update, a theme edit, a server setting, a migration, a new redirect rule or a traffic spike. Most faults follow a change.
- Read the logs. Server error logs, application logs and, if you use one, your CDN logs will name the failing process, file or request. Guessing without logs is slow and risky.
- Isolate and fix the cause. Disable the suspect plugin, restore the last good configuration, restart the failed service, fix the redirect rule or repair the link. Change one thing at a time so you know what worked.
- Validate and monitor. Reload the page, test related URLs, and confirm the correct status code. Then watch logs and your uptime monitor for repeat faults.
Always keep a recent backup before step five. A reliable backup turns a risky fix into a reversible one, and our website backup and security service is built around that safety net.
Find Error Pages With Google Search Console and Crawlers
Google Search Console is the most reliable free way to see how Google experiences your faults. Open the Page indexing report and look at the list of reasons pages are not indexed. Three rows matter most for this guide: Not found (404), Soft 404, and Server error (5xx). Click each row to see the affected URLs, inspect a sample URL to confirm the live status, and note patterns such as a whole folder failing after a deployment.
A crawler gives you the view Search Console cannot. Free and paid desktop crawlers request every URL on your site and report status codes, redirect chains, broken internal links and pages that return the wrong code. Run a crawl after every migration, redesign or major content clean-up. Your hosting analytics and server logs add a third view, showing which missing URLs real visitors and bots request most often, which tells you what to redirect first.
After you fix a group of URLs, use the validation option in Search Console so Google rechecks them. Validation can take some time, so keep monitoring instead of waiting for a confirmation. If your site runs on WordPress, our WordPress SEO optimization work includes cleaning up crawl errors, redirects and indexing issues so these reports stay healthy.
Design a Custom Error Page That Keeps Visitors
You cannot prevent every fault, but you can control what visitors see. A good error page keeps people on your site and points them towards the next step. Use this checklist.
- Return the correct status code. A page for missing content should return 404 or 410, and a server failure page should return a 5xx code, never 200.
- Match your branding. Use your logo, colours and fonts so visitors know they are still on your site.
- Explain the problem in plain language. Say that the page could not be found or that you are having trouble right now, without technical jargon.
- Offer a path forward. Add a search box and links to your main services, popular pages and contact page. For server faults, link to a status page or a way to reach support.
- Keep it accessible and mobile friendly. The layout must work on every device and with screen readers.
- Use a clear page title. A title such as Page Not Found followed by your site name helps both users and search engines understand the page.
If your current error pages are generic theme defaults, a custom website design project is the natural place to build branded 404 and 5xx pages together with the rest of your site.
Prevent Website Faults With Monitoring and Maintenance
Prevention is cheaper than repair. A small set of habits removes most of the faults described in this guide.
- Monitor uptime and response codes. Use an uptime monitor that checks your key pages every few minutes and alerts you by email or messaging when a check fails. Monitor important pages, not only the home page.
- Update on a schedule and test first. Apply plugin, theme and core updates in a staging environment or in controlled windows, and keep a rollback plan.
- Keep reliable backups. Store backups off the server and test that a restore actually works.
- Protect the site from malware and attacks. Compromised sites often show 500 errors, redirects and injected pages. Regular scanning and hardening reduces this risk, and our WordPress security and malware removal service helps when a site has already been affected.
- Size your hosting for real traffic. Undersized plans cause 503 and 504 errors during campaigns, seasonal peaks and traffic spikes. Review CPU, memory and database usage regularly.
- Improve performance. Caching, image optimisation and efficient queries lower the chance that slow processing turns into a timeout. Our speed and performance optimization service targets these causes.
- Have someone own it. Faults get fixed faster when a named person or team is responsible. A managed website maintenance and support plan gives you monitoring, updates and a quick response in one place.
FAQs About inurl:fault and Website Error Pages
What does inurl:fault do in Google?
It is a Google search operator that asks for pages with the word fault in the URL. It can be combined with the site: operator to look for fault or error related URLs on your own domain, but results can be inconsistent, so use Google Search Console, server logs and a crawler for a dependable audit.
Do 404 errors hurt SEO?
A 404 for a page that genuinely does not exist is normal and does not by itself harm the rest of your site. 404 errors become a problem when they affect important pages, lose traffic from old URLs or come from broken internal links. Fix those with correct links and relevant 301 redirects.
Is a 503 error bad for SEO?
A short 503 during maintenance is understood as temporary and is usually safe. A 503 that lasts for days can cause pages to be dropped from the index, so fix long outages quickly and use a Retry-After header for planned downtime.
Should I use a 404 or a 410 for deleted pages?
Use 404 for most missing pages. Use 410 when you have removed a page permanently and want to say so clearly. The difference in how Google treats them is small, so choose the approach your server can apply consistently.
How do I fix a 500 internal server error quickly?
Take a backup, read the server error log, deactivate plugins to test for a conflict, reset the .htaccess file, raise the PHP memory limit if the log shows a memory error, and contact your host if the fault continues.
Conclusion and Next Step
Website faults are a normal part of running a site, but they do not have to cost you traffic or customers. Remember three things from this guide. Read the status code correctly so you know whether the fault is a missing page or a server failure. Follow a fixed workflow of confirming the code, checking upstream status, reviewing changes, reading logs, fixing one thing at a time and validating the result. And invest in monitoring, backups and maintenance so faults are caught in minutes, not days.
If your site is showing 404, 500 or timeout errors and you would rather have a specialist fix it and keep it healthy, talk to our team or book a call and we will review your error pages, server responses and indexing status.’
