Tagwget

Google Webmaster Sitemap: Gekürzte Antwort Teil 2

Wie angekündigt, habe ich meine Seite nochmals mit wGet gespidert, zunächst nach der selben Methode wie im Artikel “Googlebot can’t access your site” beschrieben. Um das Logfile zu minimieren habe ich zusätzlich die Option -A html hinzugefügt, damit nur html Dateien und keine Bilder, JavaScript und Anderes herunterladen geladen wird. Im Logfile konnte ich keine Auffälligkeiten entdecken.

Als nächstes schrieb ich zwei kurze PHP-Skripte:

[PHP]
// file: start.php

$link = mysql_connect(DB_HOST, DB_NAME, DB_PASSWORD);
if (!$link) {
die(‘Could not connect: ‘ . mysql_error());
}

$db_selected = mysql_select_db(DB_NAME, $link);

mysql_query(“INSERT into statistik (ip, token, time1, script)
VALUES (‘”.$_SERVER[‘REMOTE_ADDR’].”‘, ‘”.$_SERVER[‘REQUEST_TIME’].”‘,'”.microtime().”‘,'”.mysql_real_escape_string($_SERVER[‘REQUEST_URI’]).”‘ );”);

mysql_close($link);
[/PHP]

und passend dazu auch

[PHP]
// file: stop.php

$link = mysql_connect(DB_HOST, DB_NAME, DB_PASSWORD);
if (!$link) {
die(‘Could not connect: ‘ . mysql_error());
}

$db_selected = mysql_select_db(DB_NAME, $link);

$str = “UPDATE statistik SET time2 = ‘”.microtime().”‘
WHERE ip = ‘”.$_SERVER[‘REMOTE_ADDR’].”‘ AND token = ‘”.$_SERVER[‘REQUEST_TIME’].”‘ AND script = ‘”.mysql_real_escape_string($_SERVER[‘REQUEST_URI’]).”‘;”;

mysql_query($str);

mysql_close($link);
[/PHP]

diese wurden direkt in die index.php eingebunden:

[PHP]
// file: index.php

define(‘WP_USE_THEMES’, true);

require(‘./start.php’);

/** Loads the WordPress Environment and Template */
require(‘./wp-blog-header.php’);

require_once(‘./stop.php’);
[/PHP]

Zunächst vermutete ich, das es am Favicon.ico liegen könnte

[PHP]
IP Token time1 time2 Script
6.23.4.8 1352762248 0.29693200 1352762248 0.43673200 1352762248 /5/google-webmaster-sitemap-gekurzte-antwort/2012/11/11/
6.23.4.8 1352762251 0.13867900 1352762251 /favicon.ico
6.23.4.8 1352762330 0.97333000 1352762330 0.10298000 1352762331 /5/google-webmaster-sitemap-gekurzte-antwort/2012/11/11/
6.23.4.8 1352762337 0.54685600 1352762337 /favicon.ico
[/PHP]

Also bastelte ich eines, es kam aber weiterhin zu Datenbank-Einträgen bei denen keine “time2” angegeben war.

Erst nach dem ich den WordPress Quick Cache abgeschaltet hatte, wurde auch immer eine time2 eingetragen. Mal schauen was Google bzw. Webmaster Sitemap Tools beim nächsten Crawlen sagen.

Google Webmaster Sitemap: Gekürzte Antwort

Schon seit längerem zeigen die Google Webmaster Sitemap, unter dem Menüpunkt Crawling-Fehler, an dass bis zu 78% der BugBlog Seiten eine “Gekürzte Antwort” zurückgeben. Vor einem Monat waren es noch überwiegend “Zeitüberschreitung beim Verbindungsaufbau”, die jedoch durch die Deinstallation einer WordPress-Erweiterung, mit welcher PHP-Code direkt in einen Post geschrieben werden konnte und damit inkompatibel war zu einer Erweiterung um PHP-Code hervorzuheben, behoben wurde.

Im Access-Logfile vom Apache lässt sich das Ganze nachvollziehen. Neben der Größe muss dabei auch der Statuscode berücksichtigt werden, da bspw. Urls ohne abschließenden / einen 301 (Redirect) zurückliefern. Der Aufbau findet sich hier: http://httpd.apache.org/docs/2.2/logs.html

[PHP]
[04/Nov/2012:22:28:57 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 7547 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
[08/Nov/2012:12:39:03 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 29952 “-” “Mozilla/5.0 (compatible; Infohelfer/1.3.0; +http://www.infohelfer.de/crawler.php)”
[09/Nov/2012:04:23:32 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 29950 “-” “Mozilla/5.0 (compatible; SISTRIX Crawler; http://crawler.sistrix.net/)”
[10/Nov/2012:20:14:27 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 7528 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; […])”
[/PHP]

Es ist erkennbar, das immer der Erfolgs-Statuscode 200 (OK) zurückgegeben wird, die Antwort jedoch zwischen 7547 und 29952 Bytes variiert. Kleinere Abweichungen sind dabei durchaus möglich, weil unterhalb der Posts verschiedene weitere relevante Posts angezeigt werden. Dies erklärt aber nicht eine Abweichung von bis zu 75% nach unten.

Google Webmaster Sitemap URL Fehler vom BugBlog

Als nächstes werde ich nochmal mit wget versuchen dem Fehler auf die Spur zu kommen, bzw. habe ich das LogLevel im Apache auf “info” gestellt und erhoffe mir dadurch weitere “sachdienliche Hinweise” ;-) Die Google Webmaster Sitemap bzw. der Menüpunkt Crawling Fehler lässt keine weiteren Rückschlüsse auf die Ursachen zu. So habe ich keine Einstellungsmöglichkeiten gefunden das Frontend auf Englisch umzustellen, um nach der Fehlermeldung besser suchen zu können, noch werden die fehlerhaften URLs aufgeführt.

Error 404, 500, etc. automatisch finden

Gerade bei größeren Webseiten, mit unterschiedlichen Plugins und Erweiterung, kann es vorkommen das einzelne Seiten nicht aufrufbar sind. Die Gründe dafür sind noch vielfälter als die zur Verfügung stehenden Status-Codes. In den Google Webmaster Sitemap Tools befindet sich unter der Kategorie Crawling Fehler folgende Einteilung:

  • Nicht gefunden
  • Nicht aufgerufene URLs
  • URLs durch “robots.txt” eingeschränkt
  • Zeitüberschreitung beim Aufrufen von URLs.
  • HTTP-Fehler
  • Nicht erreichbare URLs
  • Soft- 404-Fehler

Zu beachten ist dabei, das Google nicht nur die Verlinkung innerhalb der Seite überprüft, sondern auch Links von extern, welche Möglicherweise auf nicht mehr gültige URLs zeigen. Dafür eignet sich die anschließend vorgestellte Analyse Methode nicht. Im folgenden geht es ausschließlich um Links welche Innerhalb der Seite keinen 200 Code, OK bzw. Erfolgreich, zurückgeben.

Sehr anschaulich ist die Firefox Erweiterung LinkChecker, welche unter https://addons.mozilla.org/de/firefox/addon/linkchecker/ heruntergeladen werden kann.

Link Checker Ergebnis

Link Checker Ergebnis

Diese stellt in Ampelfarben, welche auch entsprechend konfiguriert werden können, die Erreichbarkeit von Links auf der jeweiligen Seite dar. In der Statusleiste gibt es zudem eine Anzeige, welche die Gesamtanzahl der Links, sowie die Anzahl der geprüften und den Fortschritt anzeigt:

Linker Checker Progress Bar

Linker Checker Progress Bar

Für größere Webseiten, welche über viele verschiedene Seiten und Kategorie verfügen, ist die händische Überprüfung mittels Firefox Plugin sicherlich nicht praktikabel. Dafür eignet sich wget. wGet ist ein kleines Kommandozeilen Tool, welches vielfältig einsetzbar ist. Für unseren Anwendungsfall benötigen wir die Spider Funktionalität:

[html]
wget -r –spider -o log.txt http://www.bugblog.de
[/html]

Wget verfolgt (-r rekursiv) alle Links innerhalb der selben Domain und läd die Dateien zum finden weiterer Links temporär (–spider) herunter. Das Ergebnis beim Aufrufen der Dateien (-o output) wird in der log.txt Datei gespeichert. Diese kann später nach den oben beschriebenen Statuscodes durchsucht werden.

Eine ausführliche Auflistung, aller möglichen Status Codes befindet sich unter: http://www.google.com/support/webmasters/bin/answer.py?answer=40132

wGet: Rekursives FTP Backup

Vor einiger Zeit hatte ich bereits mein Probleme mit NcFTP geschildert. Als Lösung für meine Problem habe ich Wget entdeckt. Viele wissen wahrscheinlich gar nicht, das damit auch FTP möglich ist.

Mein ursprüngliches Problem war, das NcFTP beim rekursiven Download ab einer bestimmten Ordnertiefe einfach aufgehört hat. Dies läßt sich bei WGet mit folgenden Parametern umgehen:

[php]
wget -r –level=100
[/php]

Trotz der Angabe von r ( r = Rekursiv ) empfiehlt es sich das Level anzugeben. Genau diesen Parameter hatte ich bei NcFTP vermisst.

Zur Vollständigkeit jetzt nochmal den kompletten Befehl für WGET um ein vollständiges Backup per FTP durchzuführen

[php]
wget -r –level=100 ftp://USER:PASS@example.com
[/php]

© 2020 BugBlog.de

Theme by Anders NorénUp ↑