Troubleshooting HTTP 404 Not Found on IIS – A System Administrator’s Guide

Enable detailed errors in IIS and take the exact requested URL, then compare it with the site bindings to identify which site or vdir is intended. This first action often reveals whether the resource is missing, lost, or resides under a different location over your infrastructure, helping you locate the owner of the mapping and the correct path quickly.

Identify whether the 404 stems from a missing file, a misconfigured virtual directory, or a redirect that points to a non-existent location. In IIS Manager, inspect the vdir settings and verify the physical path on disk, then check the permissions on the folder so the worker process can continue over different sites. If you have several sites, list their root folders and the locations they serve to prevent cross-site confusion.

For web apps using permalinks, ensure the URL rewriting rules or handler mappings do not mask a real 404 with a friendly page. Update the web.config tai URL rewrite rules, then test the internet path from a browser and from server-side logs to confirm the resulting URL resolves to an actual file or a valid route.

If the resource is not present, create a placeholder or move the file to the intended location, or configure a proper static/ASP.NET route to serve the resource. For each site, keep a record of the owner and the intended content location to speed future identifications. Use permalinks to verify that canonical URLs map to existing resources, reducing future lost 404s.

Then continue with a systematic verification: check the internet-facing URL, ensure DNS and host headers point to the correct site, and map the permalinks to a real file path. If you still see a 404, trace the request from the IIS request log, identifying where the path is lost, and adjust accordingly, documenting the changes for the owner and the team.

Analyze IIS logs for 404 patterns and failed URLs

Export the latest IIS logs and filter for 404 responses. Look for frequent URL paths and the first seen timestamp to pinpoint recurring problems affecting people trying to reach your site.

Patterns in 404s reveal common causes: missing resources, misconfigured vdir entries, and a typo in a link. Some issues originate from redirected or moved content, while others come from internal navigation or external references. Record the vdir value in your notes to keep indexing consistent. Build a list of top offenders and track counts over time to distinguish occasional misses from regularly repeating problems.

Use the referrer and user-agent fields to assess whether the issue comes from search, other sites, or direct lookups. This helps you prioritize resolving the root cause and improving the user experience with less friction.

Export a table-friendly view of 404s, including URL path, count, first seen, referrer, and notes. This print-friendly format supports updating stakeholders and maintaining a single source of truth for optimizing paths and indexing.

Actions to resolve and prevent 404s

For missing resources, restore the file or create a 301 redirect to the correct URL. For misconfigured vdirs, verify the vdir path in IIS Manager, check applicationHost.config, and ensure an existing physical path. For typos, fix the link, update content about the page, and refresh internal search indexes regularly.

Print a summarized report and share it with the support team. Keep updating a running list of changes to track what worked and what didn’t. For multiple frequent offenders, implement targeted redirects and remove dead links to reduce future errors.

Regularly review the patterns you collect, optimizing the handling of 404s, and test redirects in a staging environment before applying updates to production. This approach minimizes mistakes and helps people have a smoother experience when navigating your site.

Verify site bindings, host headers, and virtual directories

Review and correct bindings immediately: ensure the host header, IP, and port match the client’s request and that the site name corresponds to the URL in use.

Binding checks

• Open IIS Manager, navigate to Sites > [your site] > Bindings. Verify there is a binding for http (and https if used) with the correct IP and port. If multiple sites share the same IP:port, add a host name (host header) value that matches the current URL to route requests properly.

• Test requests with the exact host header: curl -I -H “Host: example.com” http://server/ or use a browser. If 404 persists, the binding may be correct but the requested path is handled by another site.

• For https, verify the certificate matches the hostname in the binding. Check the subject and SANs, and ensure the binding uses the right certificate on port 443. A mismatch can lead to failed requests that look like missing resources.

• Inspect DNS and proxy layers: ensure the incoming request carries the expected host header; a proxy misconfiguration can cause requests to land on the wrong site, yielding 404s for valid paths.

Virtual directories and path configuration

1. Verify the virtual directory alias exists under the site; the alias should appear as a URL segment (for example /files). Review the physical path in the right pane and confirm the folder exists and is accessible by the app pool identity.

2. Convert to Application when the directory should run code. Right-click the virtual directory > Convert to Application, select the correct Application Pool, and ensure the pool identity has read permissions to the physical path.

3. Check default documents if you rely on directory-level URLs; ensure there is a valid default document (index.html, default.aspx, etc.) or provide an explicit file path in your links.

4. Review web.config rules and URL rewrites that could redirect into a non-existent path. A bad rule can produce a missing-resource 404 for otherwise valid pages; adjust or remove conflicting rules.

5. Validate permissions: grant read/execute to IIS_IUSRS and the app pool identity on the physical path, and verify NTFS ACLs allow access for the expected user. Missing permissions often cause 404s that look like content is gone.

6. Test again after changes: request the problematic URL and confirm a 200 or appropriate redirect; if a redirect loops or a resource remains missing, review rewrite rules and startup logs in the application pool.

Use a basic crawl to uncover the current issue about missing pages caused by bindings or virtual directories. grep through the IIS logs for 404 entries to find which requests are failing, then address the root cause and test again into a fresh crawl. Save the results and share a concise summary with administrators and colleagues on linkedin to keep everyone aligned while you handle the issue.

Validate file paths, physical existence, and file permissions

Verify the site’s Physical Path in the IIS Manager and ensure the path exists on disk. In Basic Settings for the site or virtual directory, confirm the folder you point to contains the content you expect. If the path changed, restore the original location or correct the mapping in the snap-in so that requests address the right folder; otherwise IIS loads nothing and you see 404s.

Confirm the file actually exists on the filesystem and that the app pool identity has rights to traverse and read it. Use File Explorer or icacls to verify ACLs on the folder and all parent folders. Grant Read and List Folder Contents and Traverse to the app pool identity (for example IIS APPPOOLYourAppPool) on the content root and the files within. If permissions are incorrect, IIS indicates access denial and the engine may return 404 even when the file exists. Adjust the ACLs appropriately and re-test. If youre unsure, temporarily assign read access to a known user to confirm the file loads.

Check mime type mapping for the extensions you serve. Open the mime type for the site and ensure the extension has an associated mime type; missing mappings often yield a 404. If needed, add common types (.html, .css, .js, images, fonts) and verify the correct content-type is sent. Also verify the permalink-style URLs load from the correct folder; a mismatch between permalink route and physical path can trigger 404 for both static and dynamic assets.

Review the site’s request authorization settings. In the snap-in, navigate to the site’s Authorization Rules and ensure the client identity is allowed to read the requested folder. If a deny rule blocks the file, the engine may return 404 for some paths; removing the rule or narrowing it helps. Confirm Anonymous Authentication is enabled if you rely on public access, and check domain-level or site-level settings if multiple sites share the same content root.

Enable and check logs and tracing. Turn on Failed Request Tracing for 404 errors or review IIS logs to identify the number of hits and the requesting address. Look for the exact URL, the mapped path, and the file path from the engine; this identifying data helps locate the source. Use the information to restore a correct path, fix the load order, and prevent frustrating reoccurrences. On internet-facing sites, verify that the domain profiles and the physical path align; a small mismatch can break access for multiple sites. After changes, recycle the app pool to apply the new mappings and permissions. If youre addressing a 404 consistently, address the root cause first and then verify the user journey across all sites.

Review URL Rewrite rules and Custom Errors configurations

Export the current URL Rewrite rules from IIS for each site and compare them to a known-good baseline to pinpoint misconfigurations that lead to 404 results. This will reveal whether the issue originates in a rewritten URL, a missing resource, or an improper custom error path.

What to inspect

Locate the rules in web.config or via the URL Rewrite module for each site. Review the pattern and conditions that trigger a rewrite or redirect, and verify that the target URL points to an existing resource or a proper html page defined in Custom Errors. Confirm that the 404 entry is defined and that the path used by the error page exists under the site root. Check for conflicts between sites sharing a single application pool that map the same paths.

Audit the order of evaluation: the first matching rule stops further processing. Look for inbound or outbound rules that may capture a 404 before the custom error handler runs, and ensure there is a fallback 404 page at the configured location. Review any global or site-level settings that may override the per-site configuration.

How to apply fixes

If a rule is misconfigured, adjust the match pattern, rewrite action, and destination. Ensure a missing resource does not get rewritten to an existing path that returns a non-404 response. Update the Custom Errors section so 404 requests route to a real html file and verify the file is deployed with correct permissions. After changes, recycle the app pool and test from different client environments to confirm consistent results. Use server logs and Failed Request Tracing (FRT) data to identify the exact rule and the final response page.

Reproduce failures with targeted tests and monitor responses

Recommendation: Reproduce the 404 with targeted tests and monitor responses in a shared dashboard. Capture evidence in the accesslog and assign an owner for each pattern to speed remediation. This approach helps management see the current impact and prioritize fixes across site scopes.

Export the last 200 404 entries from the accesslog for the site. For each entry, record time, client IP, hostname, requested URL, referrer, user-agent, status, and response size. If you observe missing assets under related paths, this indicates patterns rather than isolated cases. Build a concise test list from these signals to take the next steps.

Test paths variations: request known missing URLs with and without a trailing slash; change the case of segments; append or strip query strings; compare responses for static assets against dynamic routes. Include both GET and HEAD methods to confirm the server returns 404 before any unintended redirects or rewrites occur.

Use Failed Request Tracing (FRT) when available, and cross-check with the accesslog for the same timestamps. These traces indicate which rule or module blocked the resource, or if the resource truly is missing. Tie results to a dashboard metric: count of 404s by route, by host, and by account. This excellent correlation speeds investigation and reveals current hotspots.

For resources behind a rewrite or routing layer, check related web.config, URL Rewrite rules, and any htaccess-like configurations that IIS might honor via rewrite modules. If the 404 indicates a mapping issue, adjust the rule or file path, then re-run the tests to confirm the fix before moving to production. In cases where the 404 points to a blocked resource, verify the block list or access restrictions and ensure they align with intended access patterns.

Document findings in the dashboard and share the summary with the site owner and management. If needed, publish insights to linkedin for cross-team visibility. The process should be repeatable: save the test inputs, capture responses, and attach related logs from the accesslog so they can be reviewed by the account owner or security team.

Ways to improve resilience: build a small test harness that iterates through the test list, records status codes, and flags spikes. Use these signals to take action on missing assets, update content inventories, and block noisy probes by IP only when justified. Always keep the current test suite aligned with the site inventory and MIME type mappings to prevent regressions.

Before any change, ensure you have owner approval and a rollback plan. The ongoing monitoring dashboard should indicate whether the 404 rate is stable, rising, or returning to baseline. A well-run test regime accelerates incident response and helps the team deliver a smoother user experience.