Zu viele 404

[tomjk]

Hallo, das Thema gab es schonmal, allerdings wurde es nicht so richtig allgemein aufgelöst.
Wir haben die Erweiteurng in zwei Websites integriert. Bei beiden haben wir etwwa 50% 404 User und ein vielfaches an Zugriffen. Laut google analytics komtm aber nahezu kein User auf die 404 Seiten.
Wie kann ich herausfinden woher das kommt und wie kann man es eliminieren?
Wäre klasse, wenn jemand einen Rat hat.

[BugBuster]

Was den vielfachen Zugriff betrifft, wurde vielleicht zum Test im angelegtem Zähler die Blockzeit verändert? Default sind 1800 Sekunden.
Oder das Modul aus versehen mehrfach eingebunden?

Ein 404 wird gezählt, wenn der Seitentyp "404 Seite nicht gefunden" durch internes Routing aufgerufen wird, wenn ein Zugriff keine passende Seite in der Struktur findet.
Das müsste man nun mit der Webserver Log vergleichen, um dem auf die Spur zu kommen.

[grashalm]

Hallo BugBuster,

ich greife diesen Thread noch mal auf:

Auch bei mir steht in 3 von 4 Seitenstatistiken die Error-Seite 404 ganz oben, und in der vierten Statistik immerhin noch an 3. Stelle.
Beispiel: In der "Seitenstatistik TOP 20, die 7 letzten Tage" steht:

Alias Besucher Zugriffe

seite-nicht-gefunden-404 (de) 746 809
die-schreibmaus-lothar (de) 41 44
...


Also mit haushohem Abstand führt fast überall die 404-Seite. Wie kann das sein?
Blockzeit steht bei 1800 sec., Counter ist nur einmal in der linken Spalte eingebunden, also überall zu sehen.

Unten hast Du geschrieben:

Ein 404 wird gezählt, wenn der Seitentyp "404 Seite nicht gefunden" durch internes Routing aufgerufen wird, wenn ein Zugriff keine passende Seite in der Struktur findet.
Das müsste man nun mit der Webserver Log vergleichen, um dem auf die Spur zu kommen.

Hilf mir mal auf die Sprünge: Wie und wo kann ich den Webserver-Log einsehen und was muss ich dann da machen oder beachten?

Und was bedeutete es, wenn unter dem Alias "-/-" aufgeführt ist? Das habe ich ganz oft...


Danke für Deine Hilfe!

[BugBuster]

zum dem Alias "-/-":, aus dem Quelltext:

						// Seite in der Statistik existiert nicht mehr in der Seitenstruktur
						$alias = '-/-';

Wenn also eine Seite gelöscht wurde, den Alias ändern reicht nicht, dann käme so eine Anzeige in der Statistik.

Ein weiterer Grund wäre, das der Seitentyp nicht erkannt wurde, dann ist das der Default. Das wäre dann aber untypisch und sollte nicht vorkommen.
Kann aber auch sein, das ich es in einem der Tabellen Bereiche vergessen habe, dort die Sondertypen abzufragen.
Welcher Tabellen Bereich in der Statistik wäre das bei dir?

Zu den Webserver Logdateien.
Dein Webserver, Apache oder Nginx vermutlich, legt irgendwo logdateien ab, access log Datein genauer gesagt.
Dort ist für jeden Request eine Zeile enthalten. Dort muss man nun die Zeilen suchen, die ein " 404 " enthalten. z.B.:

127.0.0.1 - - [03/Aug/2024:13:13:11 +0200] "GET /gibt-es-nicht.html HTTP/1.1" 404 22607 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"

Im Gegensatz zu einem gefundenen Seite mit " 200 ":

127.0.0.1 - - [03/Aug/2024:13:12:55 +0200] "GET / HTTP/1.1" 200 6812 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"

Jetzt kann man sich, am besten auf Kommandozeile das mal nach den 404 Seiten filtern (grep " 404 " /var/log/apache2/access.log in meinem Fall) und schauen was da alles zurückkommt.

[grashalm]

Ein weiterer Grund wäre, das der Seitentyp nicht erkannt wurde, dann ist das der Default. Das wäre dann aber untypisch und sollte nicht vorkommen.
Kann aber auch sein, das ich es in einem der Tabellen Bereiche vergessen habe, dort die Sondertypen abzufragen.
Welcher Tabellen Bereich in der Statistik wäre das bei dir?

Das ist die allgemeine Seitenstatistik TOP 20. Da habe ich etliche solcher Einträge drin.

Zu den Webserver Logdateien:
Die Kommandozeile ist nicht gerade meine Stärke... Aber ich schau mal, vielleicht kriege ich was raus...

[grashalm]

Nach langer Suche habe ich die Access-Log-Dateien schließlich gefunden und eine vom 02.08.2024 entpackt und angeschaut. Sie enthält zahllose Einträge mit 404, wie von Dir beschrieben.
Zur Anschaulichkeit hier mal 4 Zeilen aus dem Log, die 404 enthalten:

217.113.194.91 - - [02/Aug/2024:00:37:04 +0200] "GET /meine-texte/thema/anderes__jahr-1988.html HTTP/1.1" 404 605740 "-" "Mozilla/5.0 (compatible; Barkrowler/0.9; +https://babbar.tech/crawler)" "Traffic IN:992 OUT:611864" "ReqTime:2 sec"
188.165.212.137 - - [02/Aug/2024:00:37:14 +0200] "GET /texte-zum-auswaehlen/themen/lustiges__jahr-2017__sch%C3%B6nes.html HTTP/1.1" 404 606148 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)" "Traffic IN:745 OUT:616492" "ReqTime:0 sec"
217.113.194.89 - - [02/Aug/2024:00:37:15 +0200] "GET /meine-texte/thema/anderes__jahr-1992.html HTTP/1.1" 404 605824 "-" "Mozilla/5.0 (compatible; Barkrowler/0.9; +https://babbar.tech/crawler)" "Traffic IN:992 OUT:611921" "ReqTime:2 sec"
188.165.212.137 - - [02/Aug/2024:00:37:20 +0200] "GET /texte-zum-auswaehlen/themen/sch%C3%B6nes__behinderung__liebesgedichte.html HTTP/1.1" 404 606401 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)" "Traffic IN:753 OUT:616747" "ReqTime:0 sec"

Diese Einträge finden sich zu Hunderten, vielleicht zu Tausenden in der Datei.
Nach meiner laienhaften Einschätzung wurde die Seite vorletzte Nacht von Crawlern und Bots gescannt, und die Aufrufe wurden alle gezählt, zumindest in der internen Counter-Statistik.
Daher wohl auch die immensen Werte der 404-Seite überall.

Ich vermute mal, das kann man für die Zukunft nur verhindern, indem man diese Bots der Erweiterung Botdetection hinzufügt. Wobei dann natürlich irgendwann wieder andere neue Bots ähnliche Ergebnisse produzieren werden. Liege ich da mit meiner Einschätzung richtig? Oder kann man irgendetwas sinnvolles tun, um diese 404-Ergebnisse einzudämmen?
Wenn die Counter-Statistik im Backend immer "nur" dann verfälscht wird, wenn ein unbekannter Bot die Seite heimsucht, ist das ja vielleicht auch hinnehmbar. Passiert vermutlich nicht täglich. Was denkst Du dazu?

[Fehrmann]

Hi,

das hier scheint der Crawler zu sein (laut deinem Screenshot): https://www.babbar.tech/crawler

Dort stehen auch Informationen für die robots.txt und das der Crawler diese Angabe respektiert. Vielleicht hilft es ja.

Gruss
René

[mlweb]

Ich vermute mal, dass das alte Seiten von Dir sein könnten, die noch im Index von Google stehen.
Hast Du eventuell mal die Struktur Deiner Webseite geändert, aber die alten Seiten nicht weitergeleitet?

[BugBuster]

Ausgabe bei BotDetection:

CheckBotAgentSimple: User Agent als Bot ist bekannt.
CheckBotAgentExtended: User Agent als Bot ist bekannt. (Barkrowler)
CheckBotAgentSimple: User Agent als Bot ist bekannt.
CheckBotAgentExtended: User Agent als Bot ist bekannt. (MJ12bot)

Das kanns es nicht sein, denn die würden gar nicht gezählt werden.

Aber ich werde das speziell für nicht mehr existierende Seiten noch mal testen.

Es könnte natürlich ein weiterer Bot bei sein, der nicht erkannt wurde. Oder ein Bot mit realem UserAgent, was Google Bot gerne tut.

[BugBuster]

Bei mir sind das auf einer Seite auch tausende. Alles Zugriffsversuche auf"/wp-..." oder "/typo3..." , also da sucht ein Bot nach Wordpress oder Typo3 Seiten.
Sowas müsste ich mal bei mir mittels .htaccess raus filtern, damit das gar nicht erst zu Contao kommt.

[grashalm]

Vielen Dank für Eure Antworten!

Ich vermute mal, dass das alte Seiten von Dir sein könnten, die noch im Index von Google stehen.
Hast Du eventuell mal die Struktur Deiner Webseite geändert, aber die alten Seiten nicht weitergeleitet?

@mlweb:
Das scheint mir im Moment am wahrscheinlichsten zu sein. Ich habe erst vor relativ kurzer Zeit massive Umbauten an der Seitenstruktur getätigt,
und ich kann mir gut vorstellen, dass viele davon noch im Index von Google stehen.
Was muss / kann ich tun, damit Google diese alten Seiten aus dem Index löscht? Reicht da ein aktueller neuer Scan meiner Seite von Google aus?

Kann aber auch sein, das ich es in einem der Tabellen Bereiche vergessen habe, dort die Sondertypen abzufragen.

@BugBuster:
Heißt das, Du kannst da programmiertechnisch noch was verbessern?

[BugBuster]

Vielen Dank für Eure Antworten!
@BugBuster:
Heißt das, Du kannst da programmiertechnisch noch was verbessern?

Nicht bei "Seitenstatistik TOP 20", da sind die beachtet. Wenn Seiten in der Statistik mal drin waren und danach in der Seitenstruktur gelöscht werden, dann kommt es zu "-/-", da ich ja dafür dann keinen Alias mehr finde.
Könnte man natürlich auch raus filtern. Macht kaum Sinn das anzuzeigen, oder?

[grashalm]

Stimmt!

[mlweb]

Was muss / kann ich tun, damit Google diese alten Seiten aus dem Index löscht? R

Die Seiten deren Inhalt noch existiert nur unter einer anderen URL konsequent aus die passende neue URL weiterleiten (301 Weiterleitung).
Die Seiten deren Inhalt gar nicht mehr existieren mit einem Gone belegen (410 Weiterleitung).

Das kann man mit der .htaccess machen (zu mindestens auf einem Apache-Server) oder man nutzt die Erweiterung URL Rewrite von Terminal 42
Solche Weiterleitungen sind auch für SEO sehr wichtig.
Über site:deinedomain.de (ohne www) im Suchfeld Deines Browsers siehst Du schon mal alle Seiten die bei Google noch im Index sind und kannst darüber auch gut prüfen, ob Deine Weiterleitung funktioniert.
Nach und nach verschwinden dann alle falschen URLs. Ich habe das letztens bei einer recht großen Seite durchgezogen, bei der es noch Treffer aus einer Seitenstruktur von vor fast 10 Jahren gab. So ca. nach 2 Monaten war fast alles sauber und als angenehmer Nebeneffekt hat sich die Sichtbarkeit der Domain auch fast verdoppelt.

[grashalm]

Die Seiten deren Inhalt noch existiert nur unter einer anderen URL konsequent aus die passende neue URL weiterleiten (301 Weiterleitung).
Die Seiten deren Inhalt gar nicht mehr existieren mit einem Gone belegen (410 Weiterleitung).

Das kann man mit der .htaccess machen (zu mindestens auf einem Apache-Server) oder man nutzt die Erweiterung URL Rewrite von Terminal 42
Solche Weiterleitungen sind auch für SEO sehr wichtig.

Ich habe vor kurzem zahlreiche Texte, die in separaten Artikeln auf eigenen Unterseiten standen, in einzelne News umgewandelt. Sie existieren also noch, aber unter einer völlig anderen URL und in einer neuen Struktur. Die alten Seiten mit den Artikeln habe ich natürlich komplett gelöscht. Wenn sie jetzt nicht mehr exististieren, wie kann ich dann eine Weiterleitung einrichten (301)?
Kann denn die Erweiterung von Terminal 42 erkennen, welche Seiten ich mal hatte, wenn sie inzwischen gelöscht sind?

Ich habe auch einen Account in der Google Search Console. Kann ich damit was bewerkstelligen, was mir helfen würde? Falls ja, bitte eine genaue Beschreibung geben, weil ich die Oberfläche sehr unübersichtlich finde. Vielen Dank!

[mlweb]

Ich habe vor kurzem zahlreiche Texte, die in separaten Artikeln auf eigenen Unterseiten standen, in einzelne News umgewandelt. Sie existieren also noch, aber unter einer völlig anderen URL und in einer neuen Struktur.

Dafür schreibst Du in Deine .htaccess so etwas wie

RewriteEngine On
RewriteRule ^alte-seite.html$ /neue-seite.html [R=301,L]

Im Internet gibt es viele Beispiele und Erklärungen (einfach nach "Rewrite htaccess" suchen).
Je nach Strukturänderungen findet sich vielleicht ein "Muster" (z.B. alle Unterseiten mit deine_domain.de/alter_pfad/seitenname.html nach deine_domain.de/neuer_pfad/seitenname.html - nur der Pfad verändert sich). Gibt es kein Muster, leitest Du jede URL manuell um.

Kann denn die Erweiterung von Terminal 42 erkennen, welche Seiten ich mal hatte, wenn sie inzwischen gelöscht sind?

Auch dort gibst Du die Weiterleitungen manuell (mit oder ohne Muster) ein - nur eben im Backend von Contao.

Ich selbst habe schon mit beidem gearbeitet, verwende auf einem Apache-Server aber lieber die .htaccess.

Ich habe auch einen Account in der Google Search Console. Kann ich damit was bewerkstelligen, was mir helfen würde?

Mit der Search-Console kannst Du m.E. dabei nichts anfangen - höchstens beobachten, ob alles greift.

[grashalm]

Danke für Deine ausführlichen Erläuterungen!

Da ich die einzelnen Pfade der ganzen Texte nicht mehr alle im Kopf habe (sind ja gelöscht), werde ich wohl eine Datenbank-Sicherung vom März in eine Test-Installation einspielen müssen, um sie dann dort rauszukopieren.
Da ich meine .htaccess gerne möglichst unangetastet lasse, werde ich dann die Erweiterung von Terminal 42 nehmen und es damit probieren.
Gibt es einen Richtwert, wie lange man diese Rewrite-Definitionen aktiv lassen muss, bis Google (sind es auch noch andere Suchmaschinen?) diese mitbekommen und die Pfade korrigiert hat?

[mlweb]

Prinzipiell betrifft es alle Suchmaschinen, aber Google ist ja doch die relevanteste. Ich nehme solche Weiterleitungen in der Regel nicht wieder raus (zu mindestens dann nicht, wenn ich keinen Backlinkchecker nutze), weil ja auch andere Seiten auf eine bestimmte alte URL verlinken können. Die Weiterleitungen stören ja in der Regel auch nicht wirklich, selbst dann nicht, wenn diese nicht mehr gebraucht werden.

Du musst auch nicht die alte Version wieder einspielen. Gib einfach site:deine-domain.de (ohne www) in den Suchschlitz bei Google ein, dann findest Du alles was Google derzeit kennt. Geh manuell alle Treffer durch und leite alle Seiten mit 404 von denen noch der Inhalt existiert auf die neue URL weiter (301 Weiterleitung). Alle die Du findest, bei denen der Inhalt nicht mehr existiert leitest Du auf 410 Gone. Damit ist dann der Suchindex recht schnell bereinigt.

[grashalm]

Wenn ich die URLs meiner Seite über site:die-schreibmaus.de anzeigen lasse, bekomme ich folgende Ergebnis-Struktur:

Screenshot 2024-08-11 at 11-07-11 site die-schreibmaus.de - Google Suche.png

In diesem Stil habe ich 30 Ergebnisseiten durchgeblättert, aber nirgends konnte ich einen 404-Error entdecken. Haben die sich versteckt, oder heißt das, es gibt keine?

[mlweb]

Die siehst Du nicht so. Du musst jeden Treffer anklicken. Spontan einen Treffer auf Seite 9 angeklickt (https://die-schreibmaus.de/technische-hinweise.html) und schon hatte ich "Glück" und ich habe eine 404 erwischt.
Die sind also definitiv da.
Wenn Du so viele Treffer bei Google hast, ist das manuell natürlich mühselig. Ich habe es bisher trotzdem immer manuell gemacht, weil ich in der Regel den Broken Link gleich fixe und dann teste, ob meine Rewriteregel auch wirklich so greift wie ich mir das vorgestellt habe. In den seltensten Fällen konnte ich bisher Muster zur Weiterleitung einsetzen. Es waren alles individuelle Weiterleitungen, die ich erstellen musste - bei einem meiner letzten Projekte fast 300 verschiedene Einzelweiterleitungen.
Wenn ich die Umstrukturierungen selbst vornehme, dann bereite ich schon während der Umstrukturierung die notwendigen Weiterleitungen vor und überlege auch sehr genau, ob das ganze Unterfangen wirklich sinnvoll ist. Bei Fremdinstallationen ist es schon mühselig - vor allem, wenn man da Treffer von Seitenstrukturen findet, die offensichtlich schon sehr lange nicht mehr existieren.

SEO-Tools können da auch eine Hilfe sein. Ich habe diese gezielt dafür aber bisher nicht eingesetzt, da ich von den meisten kostenfreien Tools nicht allzu viel halte und die kostenpflichtigen Tools sind für nur diese Aufgabe m.E. zu teuer und die Handarbeit der Weiterleitung (gerade, wenn keine Muster erkennbar sind) bleibt ja ohnehin erhalten. Kostenpflichtige SEO-Tools werden von mir dafür also nur dann eingesetzt, wenn ich grundsätzlich auch SEO für die Seite mache. Spezielle Broken-Linkchecker kenne ich nicht wirklich, weiß nur das einige der kostenlosen Tools von den Providern gebloggt werden. Vielleicht findest Du in diesem Beitrag etwas brauchbares. Ich meine vom Einsatz des Tools Ryte hattest Du in anderem Zusammenhang schon mal berichtet.

Nachtrag: Ich habe gerade mal noch ein paar andere Treffer geklickt. Kann es sein, dass Deine Seite gerade komplett nicht erreichbar ist?

[stefan-at-work]

Dieses Tool ist sehr hilfreich: https://www.screamingfrog.co.uk/seo-spider/


Gesendet von iPhone mit Tapatalk

[grashalm]

@ mlweb: Danke für Deine genaue Beschreibung

Habe mir jetzt gerade mal die Mühe gemacht, sämtliche Links auf den 31 Ergebnisseiten von Google zu checken: Sie sind allesamt in Ordnung - kein einziger 404-Error dabei.
Der Error, den Du vorhin beim Probieren erwischt hast, kam durch einen falschen Domaineintrag in der Rootpage zustande - es waren quasi alle Links defekt, nicht nur der eine.

Eigentlich hätte ich mir denken können, dass sämtliche Seiten richtig funktionieren: Ich hatte vor kurzem erst den contao-internen Crawler laufen lassen und nach defekten Links
suchen lassen, aber es gab keine, sonst wäre dem das wohl schon aufgefallen.

Nun ja, also von Seiten, die ins Leere laufen, können meine hohen 404-Error-Zahlen im Counter vermutlich nicht kommen. Kann mir höchstens vorstellen, dass es ein paar wenige
defekte Backlinks gibt. Kennst Du einen kostenlosen Backlinkchecker?

@ stefan-at-work: Danke für den Tipp, das Tool werde ich mal ausprobieren.

[mlweb]

Ich bin mir nicht sicher, ob der interne Contao-Crawler diese Fehler finden würde. Ich glaube nicht, dass der tote Links aus dem Googleindex berücksichtigt, lasse mich aber gern eines besseren belehren.

Mit Backlink-Checkern habe ich keine Erfahrung. Nimm doch eines aus dem oben verlinkten Artikel oder den, den Stefan verlinkt hat.

[zoglo]

Die Schnecke (Escargot) crawled nur die Links im eigenen System

[mlweb]

@zoglo Dachte ich mir doch. War aber nicht ganz sicher.

[grashalm]

Danke für die zahlreichen Tipps! Die werden mir weiterhelfen.

[Fehrmann]

Hi,

wir nutzen die Site-Audits von https://ahrefs.com/de in der kostenfreien Version. Da kommen manchmal Fehler zu Tage, die man sonst nicht finden würde. Vielleicht ist es ein Versuch wert.

Gruss
René