Das Putzlowitsch Test- und SEO-Blog
Stichwort: Statuscode

Google Webmaster-Tools: 404 Fehler von 404-Fehlerseiten verlinkt

Nicht gefunden

URL: httрs://рutzlοwitsсh.dе/wp-cοntеnt/uрlοads/2011/06/kindеrtag-

Fehlerdetails

Zuletzt gecrawlt am: 29.12.14
Erstmals erkannt am: 29.12.14

Der Googlebot konnte diese URL nicht crawlen, da keine zugehörige Seite existiert. Im Allgemeinen wirken sich 404-Codes nicht auf die Leistung Ihrer Website bei der Suche aus. Sie können sie jedoch zur Verbesserung der Nutzererfahrung verwenden.

Verlinkt über

httр://рutzlοwitsсh.dе/wp-cοntеnt/uрlοads/2011/06/kindеrtag-

Möglicherweise werden nicht alle URLs aufgeführt.

Google WMT-Fehler-404 mit Link von 404-Seite

Google WMT-Fehler-404 mit Link von 404-Seite

Das habe ich gerade in den Google-Webmaster-Tools entdeckt. Die angegebene URL zeigt in Uploads-Verzeichnis, also dahin, wo die Bilder liegen.

Wie solche URLs enstehen können, darüber habe ich ja schon ein paar Mal etwas geschrieben [1][2][3].

Selbstreferenzielle Fehler

Das Interessante ist nun aber, welche Seite in den Google-WMT als Link-Quelle (Verlinkt über…) angezeigt wird. Das ist nämlich die Seite selbst, oder genau genommen, die Fehlerseite.

Der Webserver liefert den passenden HTTP-Statuscode 404 zurück und noch einen mehr oder weniger nützlichen Text für den Nutzer. Dieser sieht den Statuscode ja normalerweise nicht.

Die Standard-Fehlerseite des Apache-Webservers ist eher schlicht gehalten:

Not Found
The requested URL /wp-cοntеnt/uрlοads/2011/06/kindеrtag- was not found on this server.

Die angeforderte URL sowieso wurde auf diesem Server nicht gefunden.

Fehlerseite 404

Fehlerseite 404

Genau da liegt wohl das Problem, denn die fehlerhafte URL wird auf der Fehler-Seite als Text (!) ausgegeben. Kein Link, nicht mal ein http:// oder https:// steht vorne dran.

Aber wie wir wissen, reimt sich Google bzw. der Google-Bot gerne mal URLs aus Sachen zusammen, die irgendwie entfernt nach einer URL aussehen.

Ein Teufelskreis?

Nun ensteht dadurch ein Problem, denn die angeblich verlinkende Seite existiert natürlich und wird auch weiterhin existieren. Es ist ja schließlich die Fehlerseite des Webservers.

Wenn ein „Link“ aber weiterhin besteht, wird Google auch immer mal wieder die Seite aufrufen um zu sehen, ob sie vielleicht doch existiert. Im Ergebnis wir dann die Link-Quelle auch immer aktualisiert und bleibt bestehen. Ein endloser Kreislauf. Oder doch nicht?

Ich könnte zwar die Fehlerseite anpassen, so das die nicht gefunden URL nicht mehr angezeigt wird, aber warum? Soll der Google-Bot doch Zeit mit Fehlern verplämpern, ist nicht mein Problem.

Die wahre Fehlerquelle

Ich habe auch die wahrscheinlich wirkliche Fehlerquelle gefunden:

Umgebrochener Linktext in Google-Groups

Umgebrochener Linktext in Google-Groups

In diesem Beitrag bei Google-Groups wir der sichtbare Linktext umgebrochen und damit die URL an der Stelle abgeschnitten, so wie es oben als fehlerhafte URL zu sehen ist. Der darunter liegende Link zum Bild funktioniert hingegen einwandfrei.

Der Text httр://рutzlοwitsсh.dе/wp-cοntеnt/uрlοads/2011/06/kindеrtag- sieht halt so schön nach einer URL aus, also nimmt Google ihn als URL mit und schickt den Google-Bot vorbei.

Wie sagt John Müller das doch so schön im Webmaster-Hangout:

„Wir möchten sichergehen, dass wir nichts verpasst haben.“

Und die Moral von der Geschicht

Trau den Google-Webmaster-Tools nicht. Zumindest nicht immer.

Wenn in den Google-Webmastertools der Beitrag bei Google-Groups als Link-Quelle angezeigt werden würde, dann wäre das wirklich hilfreich. Aber die Fehlerseite selbst als Quelle anzugeben, halte ich, nun ja, für einen Fehler.

0 Kommentare »

Geschwindigkeit vs. Sichertheit – https bremst Seite aus

Sicher ist sicher

Vor gut einem Monat habe ich meine schnurpsel.de-Website auf https umgestellt. Für das Shared-Webhosting bietet Strato zu einem monatlichen Preis von 2,99 Euro ein einfaches Single-Domain-Zertifikat an, welches ich nun hier auch nutze.

Schnurpsel mit Strato-SSL

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. So weit, so gut.

Sicher ist langsamer

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt natürlich Rechenzeit. Die ersten Test der auf https umgestellten Domain bestätigten das auch. Die Seiten werden merklich langsamer geladen. Aber wie langsam ist nun dieses Langsam, wenn es sogar merkbar ist?

Hierzu habe ich einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Google-Webmastertools: schnurpsel.de mit https

Vor der Umstellung lag die Ladezeit zwischen 0,5 und 1 Sekunde. Das ist sicher kein Spitzenwert, aber durchaus akzeptabel. Nach der Umstellung bewegt sich die Zeit im Bereich von 1,5 bis 2 Sekunden, eine merkliche Verschlechterung.

Die Zeitfresser

Die konkreten Ladezeiten habe ich mir in den Entwicklertools von Chrome angesehen. Die Timeline und die „Resource network timing“ gibt Aufschluß darüber, wie lange etwas beim Aufruf einer Seite dauert.

Da ich keine „Meßwerte“ für schnurpsel.de aus der Zeit vor der https-Umstellung besitze, habe ich die Werte für ein Testblog, auch bei Strato gehostet, als Vergleich herangezogen.

Strato ohne https

Die Timeline für schnurpsel.de sieht so aus:

Die Zeiten für „Blocking“ und „DNS Lookup“ haben nichts mit dem Webserver selbst zu tun und liegen im normalen Rahmen.

Interessant wird es dann beim „Connecting„, der Zeit für den Verbindungsaufbau mit dem Server auf der Netzwerkebene (TCP) und eben auch für die erste SSL-Aushandlung. Die Zeit hat sich von etwa 30 ms ohne SSL auf fast 300 ms mit SSL mal eben verzehnfacht.

Die „SSL„-Zeit gibt es ohne https natürlich nicht. Hier wird die verschlüsselte Verbindung mit dem Schlüsselaustausch, Prüfung des Zertifikates usw. abschließend ausgehandelt. Das schlägt noch einmal mit mindestens 250 ms zu Buche.

Die Zeit für das Senden („Sending“) kann man praktisch vernachlässigen, sie liegt immer im Bereich von wenigen Millisekunden.

Die Wartezeit („Waitung“) ist die Zeit die vergeht, bis nach dem Senden der Anforderung (Request) die Antwort (Response) beim Browser eintrifft. Für WordPress ist es die Zeit, die benötigt wird, um die Seite zu erstellen, also Laden von WordPress, der Plugins und des Themes, Datenbankabfragen, Erzeugen der Ausgabe usw. Die Zeit liegt bei der Schnurpsel-Seite höher als bei der Testseite, weil einfach viel mehr Daten zu verarbeiten sind. Die Testinstallation ist praktisch eine leere WP-Seite.

Zu guter Letzt müssen die Daten vom Server zum Browser übertragen werden, was der „Receiving“-Zeit entspricht. Auch hier dauert es bei Schnurpsel Erwartungsgemäß länger, weil mehr Daten zu übertragen sind.

Langsames SSL bei Strato

Die zusätzliche Zeit von 550 ms (300 ms + 250 ms) paßt ganz gut zu dem, was in den Webmastertools von Google angezeigt wird. Wobei das eher die Untergrenze darstellt, die Verlängerung der Ladezeit durch SSL kann auch höher ausfallen.

Srato mit https (700 ms)

Letztendlich stellt sich mir nun die Frage, was besser oder schlechter ist. Die deutlich merkbar längere Ladezeit spricht gegen https, das mehr an Sicherheit, verbunden mit größerem Vertrauen und „Professionalität“, aber dafür.

Ich werde bei https bleiben und hoffe einfach, daß Strato da irgendwie noch was an der Geschwindigkeit verbesserm kann. Bei anderen Sachen haben sie es ja früher oder stäter auch geschafft. :-)

12 Kommentare »

Das Strato SSL Zertifikat – gut für den Nutzer (und für Google)

Sicher ist sicher

Gestern bestellt, heute schon aktiv, so schnell ging das mit dem Strato-SSL-Zertifikat für meine Domain schnurpsel.de. Zu erkennen ist das an dem Schloß-Symbol oben in der Adresszeile des Browsers.

Schnurpsel mit Strato-SSL

Alle Daten, die zwischen Eurem Webbrowser und meiner Website hin- und hergeschickt werden sind nun verschlüsselt. Das bedeutet, daß niemand mitlesen kann, welche Seiten Ihr aufruft oder welche Daten Ihr als Kommentar abschickt.

Der Spaß kostet mich zwar 2,99 Euro im Monat, aber das ist es mir wert. :-)

Das Strato Single-Domain SSL-Zertifikat

Strato bietet für die Webhosting-Pakete zwei Zertifikate an. Ein Single-Domain-Zertifikat für 2,99 Euro im Monat, das genau für die Domain gilt, für die es bestellt wird. In meinem Fall ist das schnurpsel.de, es funktioniert aber auch für www.schnurpsel.de. Das war noch nicht immer so, wie hier ein Nutzer schreibt.

Es gibt zudem ein Wildcard-Zertifikat für 9,99 Euro im Monat, das auch alle Subdomains mit abdeckt, wie z.B. testblog.schnurpsel.de oder bilderdieb.schnurpsel.de. Aber das ist mir dann doch zu teuer und die Subdomains sind praktisch nur Testseiten.

So sehen die Daten des Zertifikates aus:

Strato SSL-Zertifikat für www.schnurpsel.de

Ausgestellt ist es von Strato für www.schnurpsel.de, als Alternativ-Name ist aber auch schnurpsel.de eingetragen.

Das Zertifikat wird vom Browser ohne weitere Nachfrage akzeptiert, weil es in der Zertifikatshierarchie auf ein vertrauenswürdiges Root-Zertifikat von „Equifax Secure CA“ zurückgeht.

Besonderheiten beim Strato-SSL-Zertifikat

Viele Domains unter einer IP-Adresse

Ursprünglich funktioniert SSL nur dann, wenn unter einer IP-Adresse genau eine Website, also Domain angesprochen wird. Das liegt daran, daß die Verschlüsselung bereits bei der ersten Kontaktaufnahme des Browsers mit dem Server ausgehandelt wird und zu dem Zeitpunkt noch keine Information über die gewünschte Domain übertragen wird.

Beim Shared Webhosting der großen Anbieter wie auch Strato tummeln sich unter einer IP-Adresse aber viele Domains, so das hier SSL nicht ohne Weiteres funktioniert. Der Weg aus dem Dilemma ist eine Erweiterung des SSL-Standards von 2003 für das Multidomain-Hosting, die Server Name Indication (SNI). Hier wird der gewünschte Domainname bereits bei der Aushandlung, allerdings unverschlüsselt, übertragen.

Damit ist es möglich, auch mehrere Domains unter einer IP-Adresse mit individuellen SSL-Zertifikaten anzusprechen. Genau diese Erweiterung nutz auch Strato für die SSL-Zertifikate.

Die Sache hat eber einen kleinen Haken. Ältere Browser oder Geräte unterstützen den SNI-Standard nicht und so sind Websites damit nicht erreichbar. Der oben verlinkte Wikipedia-Artikel enthält eine Liste der Browser- und Systeme, die SNI unterstützen.

Die http auf https Weiterleitung

Damit künftig die Seite nur noch über https aufgerufen werden kann, sollten die http-Aufrufe auf https-Aufrufe weitergeleitet werde. Dazu bietet Strato im Kundenbereich die Option „SSL erzwingen“ an.

Strato-Option SSL erzwingen

Eigentlich eine feine und bequeme Sache, wäre da nicht ein Problem. Die Weiterleitung, die mit dieser Option ausgelöst wird, hat den Status 302 Found, was folgendes bedeutet:

„Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig.“

Genau das wollen wir aber nicht, die Seite soll nun immer und nur per https erreichbar sein. Richtig wäre also der Status 301 Moved Permanently:

„Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit (auch Redirect genannt). Die alte Adresse ist nicht länger gültig.“

So soll es sein. Mein Tip daher für Euch: Setzt nicht die Option im Strato-Kundenmenü aktiv, sondern macht die Umleitung in der .htaccess selber. Das ist auch nicht weiter kompliziert. Bei mir steht folgendes drin:

# HTTPS erzwingen 
RewriteCond %{ENV:HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Das muß natürlich nach dem RewriteEngine On, aber am besten noch vor allen anderen RewriteRules stehen.

Warum Strato per 302 weiterleitet, keine Ahnung. Vielleicht sollte man sie mal auf den Fehler hinweisen. Mit den Statuscodes haben die es eh nicht so, wenn ich da noch an die Sache mit dem 410 denke.

https – ein Rankingvorteil bei Google

Als ich gestern das SSL-Zertifikat bei Strato bestellt hatte, wußte ich noch nicht, daß Google heute bekannt geben würde, daß die sichere SSL-Verschlüsselung ein Ranking-Faktor ist. Tja, Zufälle gibt es manchmal. :-)

Ist also alles prima und ich habe intuitiv das Richtige getan. Oder doch nicht?

Mir ist aufgefallen, daß meine Seiten hier bei Schnurpsel jetzt langsamer geladen werden. Zumindest kommt es mir so vor. Und da die Seitengschwindigkeit auch ein Rankingfaktor ist bleibt abzuwarten, was nun passiert. Überwiegt der Vorteil durch SSL oder der Nachteil durch die schlechtere Geschwindigkeit. Ich werde sehen…

19 Kommentare »

Bildersuche wieder im grünen Bereich

Google-Suchanfragen im grünen BereichNach nunmehr etwa einem Monat hat sich seit dem Fehler bei putzlowitsch.de alles weitestgehend normalisiert.

Die in den Google-Webmastertools angezeiten Suchzahlen liegen nach den roten Zahlen vom Januar wieder überwiegend im grünen Bereich. Aber das häng eher mit dem Rückgang der Suchzahlen zum Jahreswechsel und dem Anstieg am Jahresanfang zusammen, der so praktisch jedes Jahr zu beobachten ist.

Anzahl Bilder im Index

Wie sich das Aussperren des Google-Bots konkret ausgewirkt hat, ist ganz gut an der Anzahl der putzlowitsch-Bilder im Index zu sehen:

Google-Bildersuche: Anzahl Bilder mit Site-Abfrage im Index

Von einem Tag auf den anderen waren ca. 200 Bilder aus dem Index verschwunden (Einbruch der roten Linie zw. 6. und 13. 1.), das sind bei damals etwa 700 Bildern schon fast ein Drittel. Bis die Bilder wieder zurück im Index waren, hat es wesentlich länger gedauert, als nur ein paar Tage, es waren ungefähr drei Wochen. Nach etwa drei Wochen waren auch wieder die vielen HTTP-403-Fehler in den Webmastertools verschwunden. Aber so richtig war es auch da noch nicht überstanden.

Aprikosen und Kirschen wieder da

Nicht nur in der Site-Abfrage waren 200 Bilder verwschwunden, sondern logischerweise auch in der normalen Bildersuche zu den entsprechenden Suchwörtern. Vor ein paar Tagen sind nun auch die letzten verlorenen Bilder wieder zu finden:

Google-Bildersuche: Aprikosen - Top-10-Diagramm

Die letzten Rückkehrer waren die Aprikosen und Kirschen. Einige Bilder waren ganz verschwunden, andere waren durch Kopien auf anderen Seiten oder Hotlinks ersetzt worden. Einge Bilder mußten nach der Rückkehr auch eine Abwertung hinnehmen, die sie bid heute noch nicht wieder ausgleichen konnten.

Insgesamt ist aber erstmal wieder alles weitestgehend normalisiert.

Nie den Google-Bot aussperren

Ich kann nur jedem raten, niemals den Google-Bot für längere Zeit auszusperren. :-)

Selbst wenn das nur Stunden oder ein zwei Tage sind, die negativen Auswirkungen ziehen sich möglicherweise über Wochen und Monate hin.

0 Kommentare »

Abgewertet, ersetzt und rausgeschmissen

Nun gab es von Google die Quittung für den Ausfall der Putzlowitscher Zeitung am 5. Januar 2011. In den Webmastertools werden mir derzeit gut 1200 Fehler mit dem Statuscode 403 (Forbidden) angezeigt:

Googlebot Crawl-Errors: PZ am 9.1.2011

Ein Umzug mit Verzug

Am 5. Januar war der Google-Bot zuletzt gegen 1.30 Uhr bei putzlowitsch.de zu finden. Dann erfolgte seitens des Webhosters der Umzug auf einen neuen Server und somit bekamen alle dort gehosteten Seiten eine neue IP-Adresse. Für die dort registrierten Seiten war das auch kein Problem, nach kurzer Zeit waren die DNS-Server aktualisiert und Besucher und Suchmaschinenbots bekamen die Seiten wieder normal zu sehen.

Einige Seiten, die bei anderen Anbietern liegen, werden aber per DNS-A-Record auf den Webspace beim umgezogenen Server umgeleitet und da stimmte die IP-Adresse dann nicht mehr, weil diese Einträge nicht automatisch aktualisiert werden.

Gegen 7 Uhr hatte ich das bemerkt und zunächst den Eintrag für meine wichtigste Seite, die „Putzlowitscher Zeitung“, angepaßt. Im Laufe des Vormittags hatte sich dann auch fast alles wieder eingerenkt, die normalen Besucher und z.B. der Yahoo-Bot (gegen 8.30 Uhr) und der Bing-Bot (gegen 9.30 Uhr) kamen wieder auf die Seite.

Nur der Googlebot ließ sich nicht blicken. Erst am 6. Januar hat er gegen 2.30 Uhr wieder die Putzlowitsch-Seite besucht. Ungünstigerweise ist er außerdem noch in meine Bot-Falle getappt, denn auch die robots.txt war für ihn mehr als 24 Stunden nicht abrufbar. Somit gab es aus Sicht des Google-Bots keinerlei Zugriffsbeschränkungen.

Abgewertet, ersetzt und rausgeschmissen

Google-Bildersuche: KartoffelSeit gestern verabschieden sich so langsam auch einige meiner Seiten, besonders Bilder, aus den Google-Suchergebnissen.

Dabei kann man drei unterschiedliche Ergebnisse sehen. Im einfachsten Fall werden die Bilder zunächst nur um ein paar Plätze im Ranking abgewertet. Je nach Position hat das auch die Verschiebung auf eine hintere Trefferseite zur Folge. Vermutlich ist das aber nur ein Zwischenschritt zum zweiten und dritten Fall.

Falls es eine identische Kopie oder das Bild in einer weiteren Version auf einer anderen Webseite gibt, wird nun die Kopie angezeigt, aber an einer schlechteren Trefferposition. So ist das z.B. bei der Kartoffel der Fall (siehe Screenshot). Mein Kartoffelbild lag in den letzten Wochen recht konstant auf Platz vier, die Kopie wurde nun an Position 8 einsortiert. Interessanterweise wird bei der Suche nach „Ähnlichen Bilder“ aber weiterhin meine Kartoffel angezeigt.

Im schlimmsten Fall sind Bilder ganz aus den Suchergebnissen verschwunden. So ist es z.B. den Kartoffeln, der Karotte und der Möhre ergangen.

Positiv denken

Etwas Gutes hat die Sache natürlich. So kann man mal sehen was passiert, wenn plötzlich gut rankende Bilder gesperrt werden und wo es eventuell noch andere Kopien der Bilder gibt. Der Witz ist, daß ich genau so etwas gerade als kleines Experiment in Angriff nehmen wollte, allerdings nicht in dieser Breite mit so vielen Bildern. :-)

Leider ist auch mein Bilder-SERPs-Überwachungstool noch nicht ganz fertig, so daß ich nun ständig „manuell“ nachgucken muß, was mit den Bildern passiert. Ich bin auch mal gespannt, wann sich alles wieder normalisiert. Dann könnte ich ja nochmal mit meinem eigentlichen Experiment durchstarten.

0 Kommentare »

Komischer Spam und der HTTP-Statuscode

Crawling-Fehler Google-Webmastertools

Komischer Link

Hin und wieder schaue ich mal in die Google-Webmastertools, wie es so um meine Seiten bestellt ist. Neben allerlei anderen, nützlichen Sachen gibt es auch eine Übersicht, welche Probleme es möglicherweise beim Abfragen der Seiten durch den Google-Bot in letzter Zeit gab. Und diese Übersicht zeigt mir im Moment dieses hier an.

Gut, die Fehler 1,2 und 4 sind klar, die kann ich nachvollziehen, aber was bitte ist Fehler 3?

/warning_this_is_english_domain_to_solve_this_problem_submit_site_in_atoall.com.html

Wenn ich irgend sowas Seltsames finde, suche ich erstmal bei Google, was das denn bedeuten könnte. Das Ergebnis hat mich dann doch überrascht. Diese komische, nichtexistierende Seite gibt es auf einigen Tausend Domains. Wenn man die Suche nur auf deutsche Seiten beschränkt, findet man sogar prominente Seiten wie www.ard.de oder www.wetter.de.

Aber wieso nimmt Google diese vermutlich nicht wirklich existierenden Seiten in den Index auf, die offensichtlich Ergebnis einer, wie auch immer gearteten Spamaktion sind?

HTTP-Statuscode

Hier kommt nun der HTTP-Statuscode ins Spiel, denn was im Fehlerfall dem Nutzer angezeigt wird, ist das eine. Viel wichtiger ist aber, mit welchem Antwortcode die Seite ihr Ergebnis zurückliefert. Bei einem „normalen“ Fehler, wie z.B. einer nichtexistierenden Seite, sollte das der Code 404 Not Found sein. Zu den Statuscodes hatte ich bereits vor einiger Zeit etwas geschrieben. Was machen aber alle die Seiten, die man in der Google-Suche zu der seltsamen URL findet. Sie geben einfach den Code 200 Ok zurück, damit geht der Google-Bot davon aus, daß die Seite existiert, und nimmt sie in den Index auf.

Manche Seiten zeigen zumindest dem Nutzer an, daß ein Fehler aufgetreten ist. Die zwei oben genannten Beispiele tun aber so, als sei alles in Ordnung und präsentieren dem Nutzer die Startseite. Das finde ich ohnehin immer ein Unding, weil der Nutzer überhaupt nicht mitbekommt, das etwas nicht stimmt. Gut, man muß nun den User auch nicht unbedingt mit einer spartanischen Fehlermeldung wie hier auf schnurpsel.de erschrecken, aber so zu tun, als sei nichts passiert, ist auch nicht der richtige Weg. Wenigstens sollte man den Statuscode 404 ausliefern, den sieht der Nutzer ja nicht.

Meine Deutung

Ich würde diese Sache mal als Webmaster-Spam verbuchen, denn die Treffer in der Google-Suche findet man nur mit der vollständigen URL. Hätte der „Spamerfinder“ es auf Google-Treffer abgesehen, hätte er die einzelnen Wörter mit Bindestrichen und nicht mit Unterstrichen trennen müssen.

Aber Webmaster, die sich entweder mit den Google-Webmaster-Tools oder einfach mit den Errorlogs des Webservers die Fehler hin und wieder ansehen, stoßen auf diese URL. Eventuell ist ja der eine oder andere Neugierig, zumal der gelesene URL-Text irgendwie nach einer Systemmeldeung klingt, und besucht die Seite am Ende der URL. Naja, und was er da dann findet…

Nachtrag (2.11.):
Der Sachverhalt mit den komischen URLs ist schon jemandem 10 Tage vor mir aufgefallen, wie ich hierrüber entdeckt habe. Ähmmm, stand ja auch schon im ersten Kommentar. Ich sollte die Kommentare mal ernst nehmen :-)

Beste Grüße nach Görlitz :-)

4 Kommentare »