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 oder 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.

Bestätigen Sie, dass die Datei tatsächlich im Dateisystem vorhanden ist und dass die Identität des Anwendungspools über die erforderlichen Rechte verfügt, um sie zu durchsuchen und zu lesen. Verwenden Sie den Datei-Explorer oder icacls, um die ACLs für den Ordner und alle übergeordneten Ordner zu überprüfen. Gewähren Sie der Identität des Anwendungspools (z. B. IIS APPPOOLIhrAppPool) Lesen, Ordnerinhalt auflisten und Ausführen auf dem Inhaltsstammverzeichnis und den darin enthaltenen Dateien. Wenn die Berechtigungen falsch sind, zeigt IIS einen Zugriffsfehler an, und die Engine kann 404 zurückgeben, selbst wenn die Datei vorhanden ist. Passen Sie die ACLs entsprechend an und testen Sie erneut. Wenn Sie sich nicht sicher sind, weisen Sie vorübergehend einem bekannten Benutzer Lesezugriff zu, um zu bestätigen, dass die Datei geladen wird.

Überprüfen Sie die Mime-Type-Zuordnung für die von Ihnen bereitgestellten Erweiterungen. Öffnen Sie den Mime-Type für die Website und stellen Sie sicher, dass die Erweiterung einen zugeordneten Mime-Type hat; fehlende Zuordnungen führen oft zu einem 404-Fehler. Fügen Sie bei Bedarf gängige Typen hinzu (.html, .css, .js, Bilder, Schriftarten) und überprüfen Sie, ob der richtige Content-Type gesendet wird. Überprüfen Sie auch, ob die Permalink-URLs aus dem richtigen Ordner geladen werden; eine Diskrepanz zwischen Permalink-Route und physischem Pfad kann einen 404-Fehler sowohl für statische als auch für dynamische Assets auslösen.

Überprüfen Sie die Autorisierungseinstellungen der Site-Anforderung. Navigieren Sie im Snap-In zu den Autorisierungsregeln der Site und stellen Sie sicher, dass die Clientidentität die Berechtigung hat, den angeforderten Ordner zu lesen. Wenn eine Verweigerungsregel die Datei blockiert, kann die Engine für einige Pfade 404 zurückgeben. Das Entfernen der Regel oder das Einschränken hilft. Stellen Sie sicher, dass die anonyme Authentifizierung aktiviert ist, wenn Sie sich auf den öffentlichen Zugriff verlassen, und überprüfen Sie die Einstellungen auf Domänen- oder Site-Ebene, wenn sich mehrere Sites denselben Inhaltsstamm teilen.

Protokolle und Ablaufverfolgungen aktivieren und überprüfen. Aktivieren Sie die Ablaufverfolgung fehlgeschlagener Anforderungen für 404-Fehler oder überprüfen Sie die IIS-Protokolle, um die Anzahl der Treffer und die anfordernde Adresse zu ermitteln. Suchen Sie nach der exakten URL, dem zugeordneten Pfad und dem Dateipfad von der Engine; diese identifizierenden Daten helfen, die Quelle zu lokalisieren. Verwenden Sie diese Informationen, um einen korrekten Pfad wiederherzustellen, die Ladereihenfolge zu korrigieren und frustrierende Wiederholungen zu vermeiden. Stellen Sie bei Websites mit Internetzugang sicher, dass die Domänenprofile und der physische Pfad übereinstimmen; eine kleine Abweichung kann den Zugriff für mehrere Websites unterbrechen. Starten Sie nach Änderungen den App-Pool neu, um die neuen Zuordnungen und Berechtigungen anzuwenden. Wenn Sie einen 404-Fehler konsequent beheben, gehen Sie zuerst die Ursache an und überprüfen Sie dann den Benutzerpfad über alle Websites hinweg.

Überprüfen Sie die URL Rewrite Regeln und die Konfigurationen für benutzerdefinierte Fehler.

Exportieren Sie die aktuellen URL-Rewrite-Regeln von IIS für jede Site, und vergleichen Sie diese mit einer bewährten Baseline, um Fehlkonfigurationen zu ermitteln, die zu 404-Ergebnissen führen. Dadurch wird aufgedeckt, ob das Problem in einer neu geschriebenen URL, einer fehlenden Ressource oder einem falschen benutzerdefinierten Fehlerpfad liegt.

Was ist zu prüfen?

Suchen Sie die Regeln in der web.config oder über das URL-Rewrite-Modul für jede Site. Überprüfen Sie das Muster und die Bedingungen, die eine Umschreibung oder Weiterleitung auslösen, und vergewissern Sie sich, dass die Ziel-URL auf eine vorhandene Ressource oder eine korrekte HTML-Seite verweist, die in 'Benutzerdefinierte Fehler' definiert ist. Bestätigen Sie, dass der 404-Eintrag definiert ist und dass der vom der Fehlerseite verwendete Pfad unter dem Site-Root existiert. Prüfen Sie auf Konflikte zwischen Sites, die einen einzelnen Anwendungspool nutzen und dieselben Pfade zuordnen.

Überprüfen Sie die Auswertungsreihenfolge: Die erste übereinstimmende Regel stoppt die weitere Verarbeitung. Suchen Sie nach eingehenden oder ausgehenden Regeln, die möglicherweise einen 404-Fehler abfangen, bevor der benutzerdefinierte Fehlerhandler ausgeführt wird, und stellen Sie sicher, dass sich am konfigurierten Ort eine Fallback-404-Seite befindet. Überprüfen Sie alle globalen oder standortweiten Einstellungen, die möglicherweise die Konfiguration pro Standort außer Kraft setzen.

Wie man Korrekturen anwendet

Wenn eine Regel falsch konfiguriert ist, passen Sie das Übereinstimmungsmuster, die Umschreibaktion und das Ziel an. Stellen Sie sicher, dass eine fehlende Ressource nicht auf einen bestehenden Pfad umgeschrieben wird, der eine Antwort liefert, die nicht 404 ist. Aktualisieren Sie den Abschnitt "Benutzerdefinierte Fehler", so dass 404-Anfragen zu einer realen HTML-Datei geleitet werden, und überprüfen Sie, ob die Datei mit den korrekten Berechtigungen bereitgestellt wird. Starten Sie nach Änderungen den App-Pool neu und testen Sie von verschiedenen Client-Umgebungen aus, um konsistente Ergebnisse zu bestätigen. Verwenden Sie Serverprotokolle und Failed Request Tracing (FRT)-Daten, um die exakte Regel und die finale Antwortseite zu identifizieren.

Reproduktion von Fehlern mit gezielten Tests und Überwachung der Reaktionen.

Recommendation: Reproduzieren Sie den 404-Fehler mit gezielten Tests und überwachen Sie die Reaktionen in einem gemeinsamen Dashboard. Erfassen Sie Beweise im Accesslog und weisen Sie jedem Muster einen Verantwortlichen zu, um die Fehlerbehebung zu beschleunigen. Dieser Ansatz hilft dem Management, die aktuellen Auswirkungen zu erkennen und die Behebung über Site-Scopes hinweg zu priorisieren.

Exportiere die letzten 200 404-Einträge aus dem Accesslog der Seite. Erfasse für jeden Eintrag Zeit, Client-IP, Hostname, angeforderte URL, Referrer, User-Agent, Status und Antwortgröße. Wenn du fehlende Assets unter verwandten Pfaden beobachtest, deutet dies auf Muster hin, anstatt auf isolierte Fälle. Erstelle aus diesen Signalen eine prägnante Testliste, um die nächsten Schritte einzuleiten.

Testpfadvariationen: Bekannte fehlende URLs mit und ohne abschließenden Schrägstrich anfordern; Groß-/Kleinschreibung von Segmenten ändern; Query-Strings anhängen oder entfernen; Antworten für statische Assets mit dynamischen Routen vergleichen. Sowohl GET- als auch HEAD-Methoden einbeziehen, um zu bestätigen, dass der Server 404 zurückgibt, bevor unbeabsichtigte Weiterleitungen oder Umschreibungen auftreten.

Verwenden Sie Failed Request Tracing (FRT), wenn verfügbar, und gleichen Sie dies mit dem Accesslog für dieselben Zeitstempel ab. Diese Traces zeigen an, welche Regel oder welches Modul die Ressource blockiert hat oder ob die Ressource wirklich fehlt. Verknüpfen Sie die Ergebnisse mit einer Dashboard-Metrik: Anzahl der 404-Fehler nach Route, nach Host und nach Konto. Diese ausgezeichnete Korrelation beschleunigt die Untersuchung und deckt aktuelle Hotspots auf.

Überprüfen Sie bei Ressourcen hinter einer Rewrite- oder Routing-Schicht die zugehörigen web.config-Dateien, URL Rewrite-Regeln und alle htaccess-ähnlichen Konfigurationen, die IIS möglicherweise über Rewrite-Module berücksichtigt. Wenn der 404-Fehler auf ein Mapping-Problem hindeutet, passen Sie die Regel oder den Dateipfad an und führen Sie die Tests erneut aus, um die Korrektur zu bestätigen, bevor Sie mit der Produktion fortfahren. Wenn der 404-Fehler auf eine blockierte Ressource hinweist, überprüfen Sie die Sperrliste oder die Zugriffsbeschränkungen und stellen Sie sicher, dass sie mit den beabsichtigten Zugriffsmustern übereinstimmen.

Dokumentieren Sie die Ergebnisse im Dashboard und teilen Sie die Zusammenfassung mit dem Website-Betreiber und dem Management. Veröffentlichen Sie bei Bedarf Erkenntnisse auf LinkedIn, um die teamübergreifende Sichtbarkeit zu gewährleisten. Der Prozess sollte wiederholbar sein: Speichern Sie die Testeingaben, erfassen Sie die Antworten und fügen Sie zugehörige Protokolle aus dem Accesslog hinzu, damit diese vom Kontoinhaber oder dem Sicherheitsteam überprüft werden können.

Möglichkeiten zur Verbesserung der Ausfallsicherheit: Erstellen Sie eine kleine Testumgebung, die die Testliste durchläuft, Statuscodes aufzeichnet und Spitzenwerte markiert. Verwenden Sie diese Signale, um Maßnahmen bei fehlenden Assets zu ergreifen, Inhaltsverzeichnisse zu aktualisieren und störende Sonden per IP nur bei Bedarf zu blockieren. Achten Sie stets darauf, dass die aktuelle Testsuite mit dem Site-Inventar und den MIME-Typ-Zuordnungen übereinstimmt, um Regressionen zu vermeiden.

Vor jeder Änderung ist sicherzustellen, dass die Genehmigung des Eigentümers und ein Rollback-Plan vorliegen. Das fortlaufende Monitoring-Dashboard sollte anzeigen, ob die 404-Rate stabil ist, steigt oder zum Ausgangswert zurückkehrt. Ein gut durchgeführtes Testprogramm beschleunigt die Reaktion auf Vorfälle und hilft dem Team, eine reibungslosere Benutzererfahrung zu bieten.