curl -I -o /dev/null -w "%{http_code}" https://example.com
HTTP 404 Not Found indicates the server cannot find the requested resource. Either the URL never existed, the resource was moved without redirect, the resource was deleted, or the URL is wrong (typo, broken link). 404 is one of the most-encountered HTTP status codes — every broken link on the internet produces one.
404 has SEO and UX implications. From SEO: search engines remove 404 URLs from their index over time; broken-link 404s waste crawl budget. From UX: users encountering 404s get frustrated and may leave the site entirely. Custom 404 pages with helpful navigation (search, popular content, sitemap link) recover some of these users.
From a security perspective, 404 vs 401/403 is an information-disclosure choice. A 404 reveals nothing about whether the path could exist with different access; a 401 or 403 reveals "this exists but you cannot access it". Some applications return 404 for protected resources to obscure existence — security through obscurity that has tradeoffs (less reconnaissance for attackers; less clear errors for legitimate users).
Recon tools (gobuster, ffuf) look for non-404 responses to identify accessible paths. Sites returning 200 for everything (soft 404s) confuse these tools — every path appears accessible. Defenders sometimes intentionally configure this; usually it is just misconfiguration that breaks legitimate tooling.
Tools (Screaming Frog, Sitebulb, dead-links checkers) crawl sites looking for 404 responses to identify broken links. Maintenance task: fix broken links by updating references or adding redirects. Reduces user frustration and improves SEO.
Hunters test for path-based information disclosure: does the site return different status codes for paths that exist (with auth required) vs paths that do not exist? Difference indicates the existence of protected resources, useful for further targeting.
Well-designed 404 pages help recover users who landed on broken URLs. Include search functionality, popular content links, sitemap reference. Some 404 pages are creatively branded ("Page not found, but here are some suggestions"). UX consideration, not security.
Pentest reconnaissance and bug bounty hunting use wordlist fuzzing to find hidden endpoints. Tools send requests for thousands of common paths, identify any non-404 responses as potentially accessible. Standard recon technique.
Returning HTTP 200 with not-found body content breaks SEO, monitoring, and log analysis. Use proper 404 status code with helpful body content.
Default "Not Found" page with no navigation or search loses users who land there. Custom 404 page with search box, popular links, and clear navigation recovers many of these users.
URL changes without redirects produce 404s for all old URLs (in search results, bookmarks, external references). Set up 301 redirects from old URLs to new URLs to preserve UX and SEO value.
SPA servers configured to "always serve index.html for any path" do not produce real 404s. SPA framework should detect not-found routes and explicitly return 404 status (Next.js, Nuxt, Angular Universal all support this).
Sudden 404 increases indicate broken links (deployment that broke URLs, sitemap changes, removed content). Monitor 404 rate; alert on spikes. Fix promptly to limit user impact and SEO damage.
Errors like "File /var/www/html/protected/secret.php not found" leak server file paths. Use generic "Page not found" message; keep file paths in logs only.
ErrorDocument 404 /404.html. Nginx: error_page 404 /404.html;. WordPress: create a 404.php template in your theme. Most CMSes have built-in 404 customisation; the page should include search, navigation, and popular content links.curl -I -L https://yoursite.com/path for individual URL checks. Set up periodic automated crawls to catch new broken links.