Memahami Berbagai Jenis Kode Status Situs Web

Every page a browser or a crawler requests comes back with a three-digit number attached to it, before a single byte of HTML is parsed. That number is the HTTP status code, and it is the most compact diagnostic signal the web has. It tells you whether a URL exists, whether it moved, whether the move is permanent, whether the server is broken, and whether Google should keep the page in its index. Read it correctly and you can resolve most site problems in minutes. Read it wrong and you can quietly delete a site from search results.

This is a complete working reference: what each family means, the codes that actually matter in production, exactly how search engines treat each one, and the diagnostic workflow for the failures that sit underneath them.

What an HTTP status code actually is

When you request a URL, your client opens a connection to the origin server (or to a CDN edge in front of it) and sends a request. The server answers with a status line, a set of response headers, and usually a body. The status line carries the status code and a short reason phrase, like 200 OK or 404 Not Found.

The code is machine-readable intent. The body is what the human sees. Those two things can disagree, and a large share of real-world SEO damage comes from exactly that mismatch: a page that displays "Sorry, this product is gone" while the server cheerfully returns 200. Browsers, crawlers, caches and monitoring systems all act on the code, not the words on the page.

The semantics of the core codes are defined in RFC 9110, the current HTTP Semantics specification, which superseded the older RFC 723x and RFC 2616 documents. A few widely used codes live in their own RFCs: 429 Too Many Requests comes from RFC 6585, 451 Unavailable For Legal Reasons from RFC 7725, and 103 Early Hints from RFC 8297. When code and documentation disagree, RFC 9110 is the authority.

The fastest way to see a real status line for any URL is to run it through an HTTP status code checker, which issues the request from outside your network and shows you the code the origin actually returned rather than the one your browser cached.

The five status code families at a glance

The first digit is the class. Everything else is detail. If you learn nothing else, learn this table.

Family	Class	Meaning	Effect on indexing
1xx	Informational	Request received, the server is signalling something before the real response arrives	None. Interim only; a final response always follows
2xx	Success	The request was received, understood and fulfilled	Content is eligible for indexing (eligible, not guaranteed)
3xx	Redirection	The resource lives somewhere else; further action is needed to complete the request	Crawlers follow the hop and process the destination instead
4xx	Client error	The request itself is faulty, unauthorised or aimed at something that does not exist	Content is not used; an already-indexed URL is dropped
5xx	Server error	The request was valid but the server failed to fulfil it	Crawling slows; indexed URLs are held, then eventually dropped

1xx: informational

These are interim responses. The client should expect a final response afterwards, so a 1xx is never the end of a transaction. 100 Continue tells a client that sent an Expect: 100-continue header that it may go ahead and transmit a large request body. 101 Switching Protocols is what a WebSocket upgrade looks like. 103 Early Hints is the only one with real performance relevance: it lets a server send preload and preconnect hints while it is still assembling the actual response, so the browser can start fetching critical CSS and fonts earlier.

You will rarely see a 1xx in a status checker, because tools report the final response. That is correct behaviour, not a bug in the tool.

2xx: success

200 OK is the code you want on every indexable page: the request succeeded and the body is the representation you asked for. 201 Created and 202 Accepted belong to APIs and form submissions. 204 No Content means the request succeeded but there is deliberately no body, which is fine for a beacon endpoint and catastrophic for a landing page, since there is nothing to index. 206 Partial Content is what you get when a client sends a Range header for a video or a resumable download.

A 200 is a claim, not proof. It says the server successfully produced a response, not that the response is the right one.

3xx: redirection

Redirects are where most of the money is, and where most of the mistakes are. The critical distinctions are permanence and method preservation.

Code	Name	Permanent?	Preserves the HTTP method?	Use it for
300	Multiple Choices	n/a	n/a	Rare. Multiple representations exist and the client must pick
301	Moved Permanently	Yes	No — clients may rewrite POST to GET	Permanent URL changes, domain migrations, HTTP to HTTPS, canonicalising www
302	Found	No	No — clients may rewrite POST to GET	Genuinely temporary moves: A/B tests, short campaigns, geo-splits
303	See Other	No	No — forces GET on the target	Post/Redirect/Get after a form submission
304	Not Modified	n/a	n/a	Conditional requests: the cached copy is still valid, no body is sent
307	Temporary Redirect	No	Yes — the method must be preserved	Temporary moves where a POST must stay a POST; HSTS internal redirects
308	Permanent Redirect	Yes	Yes — the method must be preserved	Permanent moves on API and form endpoints

Two consequences follow from that table. First, 307 and 308 exist precisely because 301 and 302 were historically allowed to turn a POST into a GET, which silently breaks form and API endpoints. Second, 301 responses are heuristically cacheable by default while 302 responses are not, so a mistaken 301 can be pinned in browser caches for a long time and is genuinely painful to undo. Trace what a URL actually does — every hop, every code, the final destination — with a redirect tracer before you assume your rule fired the way you wrote it.

4xx: client error

The request was wrong, unauthorised, or aimed at something that is not there. 400 Bad Request means malformed syntax. 401 Unauthorized means authentication is required and either missing or invalid; 403 Forbidden means the server understood you and refuses regardless of credentials, which in practice usually points at file permissions, a WAF rule or an IP block. 404 Not Found means the resource is not there and the server will not say whether that is permanent. 405 Method Not Allowed means the URL exists but not for that verb. 410 Gone is the deliberate, permanent version of 404. 429 Too Many Requests means you are rate-limited. 451 means the content is blocked for legal reasons.

5xx: server error

The request was fine; your infrastructure was not. 500 Internal Server Error is the generic catch-all for an unhandled exception in application code. 502 Bad Gateway means a proxy or load balancer received an invalid response from upstream. 503 Service Unavailable means temporary overload or scheduled maintenance. 504 Gateway Timeout means the upstream server did not answer in time. 507 Insufficient Storage and 508 Loop Detected are WebDAV extensions you will meet mostly on misconfigured shared hosting.

The difference between 500, 502 and 504 is a routing map. A 500 points at your application. A 502 or 504 points at the hop between your proxy and your application — PHP-FPM down, an app server that stopped responding, a timeout that is set too low for a slow query.

The status codes that actually matter in practice

The IANA registry holds dozens of codes. This is the working subset: the ones you will genuinely encounter running or auditing a site.

Code	Name	What it means in practice	Typical cause when it is unexpected
100	Continue	Go ahead and send the request body	Normal for large uploads
101	Switching Protocols	Upgrading, usually to WebSocket	Normal for real-time features
103	Early Hints	Preload hints sent before the final response	Deliberate performance optimisation
200	OK	Success with a body — the target state for every indexable page	Returned for an error page (a soft 404)
201	Created	A resource was created by the request	Normal API response to POST
204	No Content	Success, deliberately empty body	A page template rendering nothing
206	Partial Content	A byte range was served	Normal for video and resumable downloads
301	Moved Permanently	This URL is retired; use the new one from now on	Migration rule with a typo, or a chain of stacked rules
302	Found	Temporary detour; keep the original URL	A permanent move mislabelled as temporary — the most common redirect error
303	See Other	Go fetch this other URL with GET	Normal after a form POST
304	Not Modified	Your cached copy is current	Normal and desirable; saves bandwidth
307	Temporary Redirect	Temporary, method preserved	Often an HSTS internal redirect, not a server rule
308	Permanent Redirect	Permanent, method preserved	Correct choice for API endpoints that moved
400	Bad Request	The server could not parse the request	Malformed URL, oversized header, bad encoding
401	Unauthorized	Authentication required or failed	A staging area left password-protected after launch
403	Forbidden	Refused, and credentials will not help	File permissions, WAF or bot rule, hotlink protection, IP block
404	Not Found	Nothing here; permanence not stated	Deleted page, broken internal link, changed slug
405	Method Not Allowed	Right URL, wrong verb	A GET sent to a POST-only endpoint
410	Gone	Deliberately and permanently removed	Intentional; the strongest "delete this" signal you can send
414	URI Too Long	The URL exceeded the server limit	Runaway query strings from faceted navigation
429	Too Many Requests	Rate limit hit	Aggressive crawling, or a rate limit that catches legitimate bots
451	Unavailable For Legal Reasons	Blocked by legal demand	Takedown notice, regional legal restriction
500	Internal Server Error	The application threw and did not recover	Fatal error in code, bad plugin or theme update, broken database call
502	Bad Gateway	Upstream returned garbage to the proxy	App server or PHP-FPM crashed behind Nginx
503	Service Unavailable	Temporarily unable to serve — overload or maintenance	Traffic spike, exhausted worker pool, deliberate maintenance mode
504	Gateway Timeout	Upstream did not answer in time	Slow query, external API hanging, timeout set too low
508	Loop Detected	The server detected an infinite loop	Redirect or include loop in configuration

How HTTP status codes affect SEO

Search engines act on status codes mechanically, and their behaviour is documented. This is the table to keep next to you during a migration.

Code	How Google treats it	Effect on an already-indexed URL	What you should do
200	Content is passed to the indexing pipeline	Stays eligible for indexing	Confirm the body matches the code — no error text behind a 200
301 / 308	Followed, and treated as a strong signal that the target should be processed	Consolidated onto the target URL	Use for every permanent move; keep the redirect in place long-term
302 / 303 / 307	Followed, but treated as a weak signal for the target	The original URL is generally retained	Only use when the move is genuinely temporary
304	Content matches the previous crawl	Minimal effect; signals may be recalculated	Serve it correctly — it saves your crawl budget
4xx (400, 401, 403, 404, 410)	Content is not used at all; all treated the same way for indexing	Removed from the index; crawl frequency of that URL declines	Redirect if a real replacement exists; otherwise let it 404 or 410
429	Treated as a server-overload signal, i.e. as a server error	Crawl rate is reduced	Whitelist verified crawlers; do not rate-limit Googlebot into the ground
5xx (500, 502, 504)	Content is ignored; crawling is temporarily slowed	Held in the index at first, eventually dropped if it persists	Fix at the origin fast — this is the highest-urgency class
503	Same handling as other 5xx, but the correct signal for planned downtime	Held short-term; harmful if it runs for weeks	Pair with Retry-After, and never return 503 for robots.txt
Soft 404	A 2xx response whose body is really an error page	Flagged in Search Console and dropped from indexing	Return a real 404 or 410, or give the page real content

301 vs 302 vs 308: choosing the right redirect

Ask one question: will the old URL ever serve content again? If the answer is no, the redirect is permanent, and you want 301 for ordinary pages or 308 where the request method must survive the hop. Google treats 301 and 308 as equivalent strong signals, and 302, 303 and 307 as equivalent weak ones.

The classic failure is shipping a site migration on 302s because the framework default is 302 and nobody checked. Search engines keep the old URLs as canonical, the new ones struggle to consolidate, and the migration appears to have "lost rankings" when in fact it never told anyone the move was real. If you are writing rules by hand on Apache, generate them with an .htaccess redirect generator rather than hand-editing regular expressions, then verify the deployed behaviour rather than the intended behaviour.

404 vs 410: which one to serve for a deleted page

Google's documentation is explicit that 400, 401, 403, 404 and 410 are all handled the same way for indexing: the content is not used, and an indexed URL is dropped. So the practical difference is one of intent and of other consumers. A 404 says "not here, no comment on why" and is the right default, including for URLs that were never valid. A 410 says "this existed, we deleted it, it is not coming back" — the correct choice for expired listings, retired products with no successor, and content you removed on purpose. Other crawlers, link checkers and internal tooling do treat 410 more decisively, so use it when you mean it.

What you should not do is redirect every deleted page to the homepage. That mass redirect is exactly the pattern that produces soft 404s, because the destination is not a genuine replacement for the requested resource. Redirect to a relevant replacement, or return a real error code.

Soft 404s: the 200 that lies

A soft 404 is a page that returns a success code while showing error content: "product not found", an empty search result, a page that renders only a template shell. Because the code says 200, the URL is treated as real, crawled repeatedly, and can be indexed as thin content until it is flagged and dropped. It wastes crawl budget on URLs that do not exist.

Two things cause almost all of them: a catch-all route that renders a friendly error page without setting the status, and a redirect from every missing URL to the homepage. Fix the status code at the framework level, not with a plugin that patches the HTML.

503 and Retry-After for planned maintenance

If you must take a site down deliberately, return 503 Service Unavailable with an informative page and a Retry-After header carrying a best-effort date or duration. That is the documented way to tell crawlers the outage is temporary. Google's guidance is blunt about the limits: a full shutdown should be a last resort and measured in one or two days, not weeks, because Google cannot refresh metadata or structured data while a 503 is being returned, and prolonged unavailability leads to pages being dropped. Where you can, limit functionality instead of taking the whole site offline.

One rule has no exceptions: never serve 503 for robots.txt. A 5xx on robots.txt stops crawling of the entire site, not just the pages you took down.

Redirect chains, hops and crawl budget

Google follows up to 10 redirect hops in a single crawl attempt before giving up. That is a ceiling, not a target. Every extra hop adds latency for real users, dilutes the clarity of the signal, and burns crawl budget. After any migration, flatten chains so that A points directly at C rather than A to B to C, and make sure no rule ever points back at its own source, which produces a loop that browsers abort with an error rather than a status code.

How to check a website's status codes

Checking by eye in a browser is the least reliable method available: the browser caches redirects, follows them silently, and shows you a rendered page rather than a status line. Do it deliberately instead.

1. Test the exact URL, not a normalised version of it. Trailing slash, protocol, www and case can each trigger a different rule. Paste the URL precisely as it appears in your logs or in Search Console.
2. Request the status without following redirects. Run the URL through an HTTP status code checker to see the first response your origin returns, before any hop is followed.
3. Trace the full chain. If the first response is a 3xx, follow every hop with a redirect tracer and record each code and destination. Note the number of hops and the final status.
4. Read the response headers. Feed them into an HTTP header parser and check Location, Cache-Control, Content-Type, X-Robots-Tag and Retry-After. An X-Robots-Tag: noindex on a 200 response removes the page just as effectively as a 404.
5. Measure the response time. A server response checker shows how long the origin took to produce the first byte, which is the number that separates "slow page" from "slow server".
6. Confirm availability from outside your network. A website status checker tells you whether the site is reachable at all from the public internet, which distinguishes a real outage from a local DNS or firewall problem.
7. Check at scale, not one URL at a time. Crawl the whole site with a broken link checker so you find the 404s your visitors hit rather than the ones you happened to think of.
8. Re-test after every fix. Confirm the new code from a clean cache. A fix that only works because your browser remembered it is not a fix.

How to read the result

A status check returns more than one number. Here is what each part is telling you.

The status code is the verdict. Compare it against what you expected the URL to do; the gap between intent and reality is the bug.

The redirect chain tells you whether your rules are stacking. One hop is healthy. Three or more usually means several historical migrations layered on top of each other and never flattened.

The response headers carry the instructions that never appear on screen. Location is where a 3xx is sending you. Cache-Control and Expires determine how long a mistake will persist in caches. Content-Type reveals pages served as the wrong MIME type. X-Robots-Tag can silently deindex a healthy 200 page. Security headers such as HSTS, Content-Security-Policy and X-Content-Type-Options are worth auditing in the same pass.

Time to first byte is the server's share of page load. Treat it against a documented target: the Core Web Vitals guidance puts a good TTFB at 0.8 seconds or less at the 75th percentile, with 0.8 to 1.8 seconds needing improvement and anything above 1.8 seconds poor. A high TTFB with a 200 code means the server works but is struggling, which is frequently the last warning before intermittent 502s and 504s appear. Separate server time from front-end rendering time with a page speed analyzer.

Uptime percentage, if you are monitoring continuously, converts to real time in a way that is worth internalising. 99% uptime is about 3.65 days of downtime a year. 99.9% is roughly 8.8 hours. 99.99% is about 53 minutes. The step from two nines to three is the one that usually pays for itself.

Mobile rendering is not a status code, but a page that returns 200 to a desktop crawler and breaks on a phone still fails its users. Confirm the rendered result with a mobile friendly test when you are auditing a template rather than a single URL.

Troubleshooting the failures underneath the codes

Some failures never produce a status code at all, because the request never reaches an HTTP layer. Those are the ones that confuse people most, because the tool reports an error rather than a number.

DNS failures

If the domain does not resolve to an IP address, there is no server to answer and therefore no status code — just a connection error. Causes cluster tightly: a nameserver change that has not propagated, an expired domain registration, a deleted or mistyped A or CNAME record, or a DNS provider outage. Compare the records your domain actually publishes against what you believe you configured using a DNS lookup, and check the A, AAAA, CNAME and NS records specifically. If the record is correct but stale locally, the answer is propagation time, not a further change.

TLS and certificate errors

A certificate problem stops the connection before HTTP begins, so the browser shows an interstitial warning instead of your page. The two dominant causes are an expired certificate and a name mismatch, where the certificate does not cover the hostname being requested — classically a certificate issued for example.com that does not include www.example.com. An incomplete chain, where the intermediate certificate was not installed, is the third: it often works in one browser and fails in another, which makes it look intermittent. Verify expiry, covered hostnames and chain completeness with an SSL certificate checker, and automate renewal so the expiry case cannot recur.

5xx errors from the origin

Work outward from the application. Read the server error log first — a 500 almost always has a stack trace behind it naming a file and a line. If the log is silent at the application layer, the failure is in front of it: check whether the app server or PHP-FPM process is running for a 502, and whether an upstream timeout is shorter than your slowest query for a 504. For a 503, check worker pool exhaustion, memory limits and traffic level before assuming a code fault. If the errors started immediately after a deployment, plugin update or theme change, roll that back before debugging anything else.

Redirect chains and loops

A loop — A redirects to B, B redirects back to A — produces a browser error rather than a status code, because no final response is ever reached. The usual cause is two systems each enforcing a rule the other undoes: an application forcing HTTPS while a load balancer forces HTTP, or a CMS canonicalising a trailing slash that a server rule removes. Decide which layer owns canonicalisation, remove the rule from the other layer, and re-trace the URL. Long chains from historical migrations should be flattened to a single hop at the same time.

Mixed content on HTTPS pages

When an HTTPS page loads subresources over plain HTTP, browsers intervene. Modern browsers split this into upgradable and blockable content: images, audio and video are automatically upgraded to HTTPS where possible, while scripts, stylesheets, iframes, fonts and fetch or XHR requests are blocked outright. Blocked stylesheets and scripts are why a page can return a clean 200 and still render as broken text with no styling.

Fix it at the source by serving every asset over HTTPS, using protocol-relative or absolute HTTPS URLs, and replacing third-party embeds that only offer HTTP. A Content-Security-Policy: upgrade-insecure-requests header forces the upgrade across the board as a stopgap. Confirm the certificate and HTTPS configuration are sound in the first place with an HTTPS checker.

Broken links

Broken internal links generate 404s that are entirely your own doing: a renamed slug, a deleted page still linked from navigation, a typo in a hand-written href. Broken outbound links point at pages someone else removed. Both waste crawl budget and frustrate readers, and neither shows up until you crawl for them. Run a full crawl on a schedule rather than reacting to complaints, and fix each hit at the source by updating the link, rather than by adding another redirect rule on top of the pile.

What to monitor continuously

Spot checks find the problem you already suspect. Monitoring finds the one you do not. A useful monitoring setup covers four distinct jobs, and most teams need at least the first two.

Monitoring type	What it watches	What it catches	Who needs it
Uptime	Reachability and status code at a fixed interval	Outages, sustained 5xx, DNS and certificate failures	Every site
Performance	Response time, page load, Core Web Vitals	Gradual degradation before it becomes an outage	Every site with meaningful traffic
Security	Malware, unexpected file changes, vulnerable components	Compromises and injected content	Sites handling accounts or payments
Transaction	Scripted user journeys: login, add to cart, checkout	Flows that break while every individual page still returns 200	Ecommerce and SaaS

Transaction monitoring is the one most teams skip and then regret. Every page in a checkout can return 200 while the payment step silently fails; only a scripted journey catches that.

What to look for when you choose a monitoring tool

Judge candidates on six things. Reliability comes first: a monitor that misses outages or fires false alarms is worse than none, so look for frequent checks from multiple geographic locations and confirmation from a second location before an alert fires. Clarity matters next — you should be able to read a result without decoding it, because you will be reading it at an inconvenient hour. Configurability means choosing check intervals, locations and what to watch: status codes, response time, certificate expiry, DNS records, or a specific string in the response body. Alerting should support more than one channel, with escalation and sensible thresholds, so a single blip does not page anyone but three consecutive failures do. History and reporting turn incidents into trends: without retained data you cannot tell a one-off from a pattern that has been building for a month. Integrations with your CMS, hosting, issue tracker and chat put alerts where your team already works.

Beyond outage detection, continuous checks give you three things a spot check cannot: they find errors across the whole site instead of the pages you thought to test, they detect problems before users report them, and they build the historical record that tells you whether a change helped.

A maintenance routine that prevents most status code errors

Most 4xx and 5xx errors are preventable, and the preventive work is unglamorous.

1. Back up files and database on a schedule, and test a restore. An untested backup is a hypothesis. Being able to roll back turns a fatal 500 from an emergency into an inconvenience.
2. Keep the CMS, plugins, themes and dependencies current. Outdated components cause a large share of 500s and nearly all avoidable compromises. Update on staging first.
3. Review server configuration after every change. Permissions, rewrite rules, PHP and memory limits, and upstream timeouts are all places where a small edit produces a site-wide 403 or 502.
4. Watch your error logs. The log names the file and line. Guessing from the browser does not.
5. Test on real devices and multiple browsers. Some failures are client-specific — an incomplete certificate chain or a blocked mixed-content script may only surface in one browser.
6. Document each fix. A short internal note of symptom, cause and resolution turns the second occurrence of a problem into a five-minute job.
7. Escalate when the pattern is beyond you. Intermittent 5xx under load, or errors that appear only for some users, usually need someone with access to infrastructure metrics. Bring in your host or a system administrator rather than changing configuration at random.

There are matching mistakes to avoid. Testing only the homepage hides errors that live deep in the site. Assuming a browser error is a server error skips the DNS and TLS layers entirely, where the real fault often is. Relying on automated tools alone means you never load the page as a user and never see the broken rendering behind a clean 200. Changing production configuration without a backup turns a small problem into a large one. And ignoring server-side logs while staring at the front end is the single most common reason a 500 takes a day to fix instead of ten minutes.

Frequently asked questions

What is the difference between a 301 and a 302 redirect?

A 301 says the move is permanent and the new URL should replace the old one everywhere; Google treats it as a strong signal that the target should be processed, and browsers may cache it long-term. A 302 says the move is temporary and the original URL should be kept; Google treats it as a weak signal. Use 301 for migrations, HTTPS enforcement and retired URLs, and 302 only when the old URL will genuinely serve content again.

Do 404 errors hurt my search rankings?

A URL returning 404 is dropped from the index, but 404s are a normal part of the web and having them does not itself penalise the rest of your site. What causes real harm is 404s on URLs that should work — pages you still link to internally, URLs with external backlinks, or pages that were indexed and earning traffic. Prioritise by impact: fix or redirect the ones with links and traffic, and leave genuinely dead URLs to return 404 or 410.

When should I use 410 instead of 404?

Use 410 Gone when you deliberately removed something and it will not return — an expired listing, a discontinued product with no successor, content you took down on purpose. Use 404 as the default for anything missing where you are not asserting permanence, including URLs that never existed. Google handles both the same way for indexing, but 410 states your intent unambiguously to every other crawler and tool.

What causes a 500 Internal Server Error and how do I fix it?

500 is a generic signal that the application threw an error it could not handle. Common causes are a fatal error in code, an incompatible plugin or theme update, a broken database connection, an exhausted memory limit, or a malformed server configuration file. Start with the server error log, which names the file and line. If the errors began right after a deployment or update, roll that change back first and debug from a working state.

How should I take my site down for maintenance without losing rankings?

Return 503 Service Unavailable with an informative page and a Retry-After header giving a best-effort date or duration, and never return 503 for robots.txt. Keep it to a day or two: Google cannot refresh your metadata or structured data while a 503 is being served, and extended unavailability leads to pages being dropped. Where possible, limit functionality — disable checkout, add a banner — rather than taking the whole site offline.

Why does my page return 200 but still get dropped from search results?

Three things do this. A soft 404, where the code is 200 but the body is an error page. An X-Robots-Tag: noindex response header or a noindex meta tag on an otherwise healthy page. Or a canonical tag pointing at a different URL, which tells the search engine to index that one instead. Check the response headers, not just the code, and confirm what the page declares about itself.

Why do I get a browser error with no status code at all?

Because the request never completed an HTTP exchange. DNS failures mean the hostname never resolved to an IP, so no server was contacted. TLS and certificate errors abort the connection before HTTP starts. Redirect loops never reach a final response. Connection timeouts and refused connections mean the server did not accept the request. Diagnose these in order: resolve the DNS records, then verify the certificate, then trace the redirect path.

How often should I check my site's status codes?

Continuously for availability, and on a schedule for everything else. Monitor uptime and status codes at short intervals so an outage produces an alert rather than a customer email. Run a full crawl for broken links and redirect chains monthly for a stable site, and weekly during and after any migration. Always re-check the affected URLs immediately after a deployment, a DNS change or a certificate renewal — those three events cause most avoidable outages.

The short version

Status codes are the fastest honest answer you can get about a URL. 2xx means it worked, 3xx means it moved and you need to know whether permanently, 4xx means the request was wrong, and 5xx means you have a problem to fix now. Match the code to your actual intent — permanent moves on 301 or 308, deliberate deletions on 410, planned downtime on 503 with Retry-After — and confirm what the server really returns rather than what your configuration was supposed to do. Almost every diagnosis starts with reading the status line correctly, and almost every avoidable indexing disaster starts with not reading it at all.