Hach, als 80er-Jahre-Vollnerd bekomme ich fast schon eine Gänsehautentzündung, so schön finde ich die Überschrift. Falls Du sie nicht verstehst... sieh es mir bitte nach, ich bin alt, dafür verstehst Du dann ggf. auch nicht die nun folgende Überleitung (ätsch!): so gar nicht Basic war die letzte Woche.

Endlich war mal wieder SMX-Zeit angesagt. Zum zweiten Mal virtuell und dieses Mal quasi schon routiniert auf allen Seiten. Dieses Corona hat deutliche Verbesserungen in der virtuellen Meeting-Landschaft mit sich gebracht.

Als Moderator des PPC/SEA-Kanals durfte ich ein professionelles Setup nach dem Nächsten bestaunen. Fachlich waren die Vorträge mal wieder hervorragend! Man hatte das Gefühl eine Privatschulung zu erhalten. Sehr genial, obgleich das Konferenzknuddeln und Rudel-Smalltalken in den Pausen natürlich fehlt. Die Moderatoren-Sicht der SMX kannst Du übrigens hier im SEMrush-Talk organisiert von Astrid Kramer ansehen .

Meine Key-Learings zum immer wieder hinter die Ohren schreiben:

1. Die anderen kochen auch nur mit Wasser

2. Google ist schon längst nicht mehr der einzige Startpunkt im Internet

3. Nutzer wollen nicht mehr "billig online kaufen" sondern wollen "das Beste"

Und so war die Woche für andere Wingmenschen:

• Behrend bibbert baldiger Beendigung von Universal Analytics entgegen

• Hannah restrukturiert sich die SMX

• Matthias zeigt, dass er es nach 2 Wochen Wingmensch sein schon besser kann

• Anita mixt im Char Salat (evtl. ein SMX-Rezept vom Hanns?)
  und

• Andreas erzählt uns die Geschichten vom emsigen Google News Publisher

Viel Spaß beim Lesen, Deine Wingmen

Am 16.03.22 hat Google bekanntgegeben, was wir schon seit einer Weile erwarten. Das Sunset Datum für Universal Analytics (aka das "alte" Google Analytics): Ab dem 01.06.2023 werden keine Tracking Daten mehr verarbeitet . Danach werden die Properties mindestens noch ein halbes Jahr einsehbar sein.

Wenn Du also in Deiner Webanalyse gerne Year-over-Year-Vergleiche machen willst, musst Du spätestens am 01.06.2022 Daten in ein Neues Setup einlaufen lassen. Das ist Morgen in 10 Wochen. Wenn man die von Krista Seiden vorgeschlagene Projekt Timeline annimmt, sind es auch 10 Wochen bis die Implementierung steht. Du solltest also spätestens HEUTE Anfangen Dich darum zu kümmern.

Wenn Du sowieso gerade mit Google Analytics haderst und mit Blick auf den Datenschutz überlegst, auf eine andere Webanalyse-Lösung umzusteigen, ist das vielleicht der Grund, endlich aktiv zu werden. Welche Möglichkeiten hast Du?

Die Liste der Webanalyse Tools ist lang:

GA4, Mapp (ehemals Webtrekk), Fathom, Webtrends, Microsoft Clarity, Hotjar, Etracker, Adobe Analytics, PiwikPro, Matomo (aka Piwik(?!Pro) ), OWA und viele, viele mehr. Die Reihenfolge dieser Aufzählung ist übrigens von mir aktiv randomisiert und enthält keine Wertung.

Welches davon das richtige ist, hängt natürlich von Deinen Bedürfnissen ab. Zu GA4, Matomo und Etracker können wir aufgrund aktueller Erfahrungen Folgendes sagen:

GA4

Google präsentiert als Nachfolger für UA natürlich das neue Google Analytics 4.

GA4 hat eine Menge Vorteile, die Martijn Scheijbeler auf Twitter mal umfangreich aufgelistet hat , aber leider gibt es auch eine Menge berechtigte Contra-Argumente. Diese hat Micah Fisher-Kirshner auf Twitter schön zusammengetragen.

Dabei ist das Thema Datenschutz noch gar nicht erwähnt. Die europäische Rechtsprechung läuft zum Thema schließlich aktuell unter Volldampf. Ich denke, zumindest im Zusammenspiel mit Server Side Tagging sollte es aber langfristig möglich sein, ein datenschutzkonformes Tracking in GA4 umzusetzen.

Matomo

Matomo haben wir seit ein paar Jahren selbst im Einsatz. In der Auswertung ist Matomo ohne Zweifel unkomfortabler als Google Analytics, aber es hat auch Vorteile:

• Ein Integriertes Tag Management (kann mit dem Google Tag Manager natürlich nicht mithalten, ist aber für den "Hausgebrauch" völlig ausreichend).

• Man kann es komplett selbst hosten und out of the Box ein cookiefreies Tracking einsetzen - für sorgenfreies Datenschützen.

Um Marketing-Kampagnen zu steuern und Zielgruppen zu bilden oder ähnliches, ist Matomo definitiv nicht das Tool der Wahl. Aber wer nur grob seine Traffic-Quellen im Blick haben und wissen will, welche Landingpages funktionieren, der hat mit Matomo eine Lösung.

Etracker

Vor kurzem durfte ich einer Produktvorstellung von Etracker beiwohnen und war positiv überrascht:

• Die Auswertungsmöglichkeiten bieten so ziemlich alles, was man sich wünscht

• Als Hamburger Unternehmen mit Servern in der EU sind die Daten sicher in der EU (Stichwort: FISA )

• Plugins für diverse CMS ermöglichen einfache Implementierungen

• ein ergänzendes cookiefreies Session-Tracking

Ob die positive Überraschung in der Praxis auch eine positive Erfahrung bleibt, muss Etracker aber noch zeigen.

Wie oben erwähnt, gibt es noch Unmengen weiterer Anbieter und durch die Anforderungen von DSGVO & Co wird der Markt wahrscheinlich nachhaltig durchgewirbelt. Es lohnt sich sicherlich, die Entscheidung, wie es nach Universal Analytics weitergeht, gut zu planen.

Zwei spannende Tage auf der SMX liegen hinter mir und ich werde Euch die nächsten Ausgaben wohl noch das ein oder andere Mal mit Infos davon füttern.

Der Start am Mittwoch ging mit Philipp Klöckner und seinem Vortrag "The Unbundling of Search" gut los. Was ich mir als Hauptpunkt mitgenommen habe: die organische Suche nimmt immer weiter ab, da die Nutzer zunehmend eigene Apps nutzen  und entsprechend direkt bei Amazon, AirBnB oder Booking suchen statt bei Google. Auch Social Media mit Instagram und TikTok dürfen wir nicht außer Acht lassen mit unzähligen Affiliate Links direkt zu Produkten und Angeboten, ohne dass die Nutzer überhaupt gesucht hätten.

Erst war ich schockiert, da ich beispielsweise gar keine "extra" Apps wie Booking, AboutYou o.Ä. habe und eine Suche fast immer über Google starte. Aber man soll ja nicht nur von sich ausgehen - und dann fiel mir meine 15-jährige Nichte ein, die ausschließlich TikTok zu nutzen scheint. Je mehr ich darüber nachdenke, desto mehr Beispiele fallen mir ein von Personen, die sehr viel weniger googeln als ich.

Hab ich nun "Angst um meinen Job"? Nein. Denn ich weiß ja, warum ich bei Google starte und nicht in einer App oder auf einer Website. Die meisten Apps und Websites sind für meinen Geschmack zu schlecht, nicht nutzerfreundlich und ich würde niemals finden, wonach ich suche.

Ein weiterer spannender Vortrag war der über strukturierte Daten von Julian Dziki (Seokratie). Er hat die wichtigsten Basics erklärt und anschließend die oft gestellte Frage diskutiert, ob denn nun die Markups nach schema.org ein Rankingfaktor sind oder nicht. Dafür hatte Julian ein spannendes Beispiel von Amazon in petto: ein ausgesprochen ansprechendes Snippet inkl. Preisangabe, Bewertungen und noch mehr - und trotzdem war KEIN Markup hinterlegt.

Auch ich sehe immer mal Snippets, die aussehen, als müsste ein Markup hinterlegt sein, bei dem das aber nicht der Fall ist. Ich bin dann immer ein bisschen begeistert und beleidigt zugleich... Toll, es funktioniert auch ohne! Mist, wieso sollte man sich die Mühe machen, Markup einzubauen, wenn es gar nicht notwendig ist, weil Google sich stetig verbessert? Die Antwort ist ganz einfach: Die Markups geben Sicherheit. Sie sind der doppelte Boden. Noch sollten wir uns nicht darauf verlassen, dass Google die Elemente allein anhand der Inhalte korrekt interpretieren kann.

Mit einem Markup nach schema.org übergeben wir unsere Daten strukturiert und genau in dem Format an Google, das gewünscht ist und von dem wir sicher sein können, dass es verstanden und ausgelesen wird.

Außerdem können wir im Markup ja auch Beziehungen verdeutlichen, die sonst über die Seite hinweg gar nicht so deutlich würden - aber mehr zu einer umfangreichen Strategie rund um den Einsatz von strukturierten Daten in einem anderen Beitrag demnächst 😄

Julian hat das Produkt mit auffälligem Snippet ohne Markup im Auge behalten und festgestellt, dass von einem auf den anderen Tag die zusätzlichen Angaben im Snippet weg waren und ein Mitbewerber stattdessen ein entsprechendes Snippet durch ein entsprechendes Markup erzielen konnte. Ich erinnere an das Netz mit doppeltem Boden ;)

Das scheint auch Amazon nicht entgangen zu sein, das mit einem Product Markup nachjustierte. Dieses wurde ziemlich rudimentär gepflegt, weshalb Julian es dann mit einem sehr ausführlichen Markup von Idealo verglichen hat. Ich würde Dir jetzt sooo gerne ein paar Seiten sagen, wo Du dir mal die strukturierten Daten anschauen kannst als absolut tolle Beispiele, was ich aus Verschwiegenheitsgründen leider nicht darf - aber sollte der ein oder andere Kunde von mir mir dafür mal ein Go geben, werde ich Dir begeistert berichten :)

Julian und ich sind uns jedenfalls einig: nutze die strukturierten Daten, hinterlege Markups für Deine Produkte, Angebote und Blog Postings. Zeichne aus, was Du hast und kannst!

Ein weiterer Vortrag, der mich nachhaltig ergriffen hat, ist der von Jens Fauldrath über Publisher SEO. Auch ich betreue ein paar Publisher und konnte ihm nicht bei allen Punkten zustimmen. Deshalb werde ich nun ein paar Aspekte mehr im Auge behalten und selbst Tests erstellen, um seine Aussagen zu validieren oder ihm dann widersprechen zu können. Es bleibt also spannend.

Auf jeden Fall hat auch Jens über strukturierte Daten referiert und ich war am Ende etwas frustriert, dass einige seiner Best Practices sich ziemlich mit dem überschneiden, was ich vor einiger Zeit für einen Kunden ausgearbeitet habe und gerade mitten im Rollout steckt. Denn nun werden wohl einige Publisher ähnlich verfahren, zumindest wenn sie Jens Rat folgen. Aber eine schöne Bestätigung ist es natürlich auch.

Einig sind Jens und ich uns zum Beispiel darin, dass man nicht nur die Standard-Markups, Pflichtangaben und empfohlenen Attribute nutzen und pflegen sollte. Gehe tiefer mit Deinen Angaben, schaffe Verbindungen zwischen Deinen Produkten und Seiten, probier auch mal Attribute, die Deine Marktbegleiter nicht nutzen, und sei mutig!

Im Bereich der Structured Data ist übrigens noch mehr passiert: Schema.org Release 14.0 ist da! Besonders erwähnenswert: die neue Angabe von hasAdultConsideration , anwendbar auf Product und Offer, sowie die isFamiliyFriendly -Angabe, die nun ebenfalls auf die beiden anwendbar ist. Ich freue mich immer, wenn das Internet ein Stückchen sicherer und transparenter wird.

Zudem hat sich einiges rund um das Organization-Markup ergeben. Du kannst nun endlich (!) - an dieser Stelle ein kurzer, virtueller Trommelwirbel (mit einem Hauch von verdrehten Augen) - eine Organization als OnlineBusiness und einen Store als OnlineStore auszeichnen. Ich weiß gar nicht, welcher Emoji passender wäre "Juhu!" oder "OMG, das wurde aber auch Zeit" - sag Du's mir!

Deine Webseite ist so langsam, dass Du Dir während des Ladens noch einen Kaffee machen kannst? Halb so wild, schließlich bist Du ein großes Unternehmen und musst Dir über solche Kleinigkeiten keine Gedanken machen, richtig? 😄 Falsch! 💀

Die Performance Deiner Seite ist nämlich wichtiger, als Du denkst. Immerhin hängt sie eng mit der Qualität Deiner Seite zusammen und wenn eines klar ist, dann dass Google inzwischen immer mehr Wert auf Qualität als Rankingfaktor legt. Das bedeutet zwar nicht, dass Dich eine schnellere Seite automatisch auf Platz 1 der Suchergebnisse katapultiert, aber ohne diese Basis steht Dein Internetauftritt auf einem wackeligen Fundament. Dann bleibt nur zu hoffen, dass nicht bald ein starker Windstoß in Form eines neuen Google-Speed-Updates kommt und Deine Webseite wie ein Kartenhaus in sich zusammenfallen lässt.

Ausreden für eine schwache Performance der eigenen Seite gibt es viele: Von mangelnder Zeit über fehlendes Know-how bis hin zu fehlender Relevanz der Core Web Vitals ist alles vertreten. Dabei ist es meist gar nicht so schwer, etwas an der Ladezeit zu verbessern... Dafür gibt es inzwischen sogar Tools, die einem vorschlagen, was man besser machen kann. Jedenfalls, wenn man bereit ist, ein wenig Zeit in dieses Thema zu investieren.

Vor allem, wenn man bedenkt, dass Google - wie die letzten Updates zeigen - zunehmend gesteigerten Wert auf die Nutzererfahrung legt, solltest Du langfristig planen und nicht den Zug verpassen, schon heute an Deiner Performance zu feilen. Sonst stehst Du bald mit Deinen Produkten oder Dienstleistungen am leeren Bahnhof, während Deine Konkurrenz in der ersten Klasse die Füße ausstreckt.

Was kannst Du tun?

• Strebe nach Perfektion: Was im ersten Moment wie ein Motivationsspruch auf einer Kaffeetasse klingt, ist aus Jono Aldersons Sicht ein wichtiger Maßstab in Bezug auf die Performance. Auch wenn Du natürlich nie eine perfekte Seite erreichen wirst: Du solltest seiner Meinung nach zumindest versuchen, so nah wie möglich heranzukommen. Denn auch, wenn es sich hart anhört: Mit Platz zwei bist Du schon der erste Verlierer.

• Behalte die Performance immer im Blick: Es reicht leider nicht, einmal dafür zu sorgen, dass die Core Web Vitals im grünen Bereich sind und sich dann für die nächsten Jahre entspannt zurückzulehnen. Google führt regelmäßig Updates durch und was heute noch in Ordnung war, kann Dich morgen schon Dein Ranking und Deinen Umsatz kosten.

• Unternimm etwas: Entweder Du nimmst die Angelegenheit selbst in die Hand oder Du suchst dir jemanden von außerhalb, der das Ganze für Dich übernimmt. Wichtig ist nur, dass es überhaupt jemand macht!

Welche Tools eignen sich am besten für eine ideale Performance?

• WordPress und Shopify sind bei den CMS ganz vorne dabei.

• App Stores: AMP und Bento

• Publishing & Optimierungs Suite: Yoast

• Telco infrastructure: Cloudflare

Immer noch nicht überzeugt? Dann hab ich hier noch einen kleinen "Fun Fact" zum Abschluss: Wusstest Du, dass Du laut einer Studie mit gerade einmal 0,1 Sekunden weniger Ladezeit bis zu 10% mehr Kunden bekommen kannst? Das musst Du dir mal auf der Zunge zergehen lassen: 10% mehr Kunden durch eine Verbesserung der Ladezeit um gerade einmal 0,1 Sekunden! Zur Erinnerung: Das ist kürzer als ein Wimpernschlag und kann am Ende über Deinen Erfolg entscheiden.

Deshalb lieber gestern als heute um die Performance Deiner Seite kümmern! Denn Du weißt ja: Platz zwei ist schon der erste Verlierer.

In den letzten Wochen hat mich das Thema UX bei Twitter verfolgt. Wenn das mal kein Zeichen ist, auch hier wieder ein paar Worte dazu loszuwerden.

Los ging es mit einem Tweet von Stéphanie Walter, der sich auf diesen Post von ihr bezüglich Sonderzeichen bezog. Grundlage dafür ist Stéphanies Vortrag

Denn Probleme bedingt durch Sonderzeichen sind nicht nur super nervig, sondern können noch eine ganze Reihe negativer Folgen nach sich ziehen.

Das weckt bei mir Erinnerungen an meine Reise nach New York zur SES vor 10 Jahren. Egal wo ich mich eingecheckt habe - im Hotel, auf der Konferenz, usw. - es war immer wieder spannend herauszufinden, was aus dem "ö" in meinem Nachnamen geworden war.

Das ist mir bisher - zum Glück - tatsächlich noch nie passiert, auch wenn ich demnächst mal wieder unter dem Namen "Bohm" in ein Flugzeug steigen und wie immer Angst haben werde, dass doch noch jemand sagt: In Ihrem Ausweis steht aber was anderes!

Stéphanie erklärt, was zum Beispiel bei Online-Formularen alles schief laufen kann. Von der Validierung über die Darstellung und Codierung bis hin zu möglichen Konsequenzen im echten Leben. (und Heiko zeigte mir, dass die Missverständnisse über Namen noch größer sind, als man gemeinhin annehmen würde. )

Validierung

Die erste Hürde, die es beim Ausfüllen eines Online-Formulars zu nehmen gilt, ist die Validierung der Eingabe. Mit einem é, ö oder anderen Spezialfällen kann es durchaus vorkommen, dass der Name in der Form einfach nicht validiert wird, da diese Zeichen nicht zulässig sind. Stéphanie zeigt im Video etwa ab Minute 1:30 eine Reihe von Fehlermeldungen, die eigentlich ganz unterhaltsam wären, wäre das zugrunde liegende Problem nicht so doof.

Also Achtung, wenn Du selbst irgendwo auf Deiner Website eine Eingabe validierst, fasse da die Regeln entsprechend breit genug!

Darstellung

Im Anschluss geht es weiter mit dem Thema Schriftarten. Die sind natürlich essentiell für eine korrekte Darstellung. Schade nur, wenn im genutzten Font nicht alle erforderlichen Zeichen existieren. Bei uns gibt es ja im Normalfall nur wenige Ausnahmen vom regulären A-Z - ä, ö, ü und ß. Es gibt aber sehr viele andere Sprachen, in denen es noch zahlreiche weitere Besonderheiten gibt, zum Beispiel im Französischen, Griechischen oder in slawischen Sprachen.

Hier muss also schon beim Design der Website daran gedacht werden, dass und welche Zeichen die verwendete Schriftart abdecken sollte.

Encoding

Aber nicht nur bei der Darstellung im Frontend müssen Sonderzeichen korrekt verarbeitet werden. Auch bei der Verarbeitung im Backend kommt es zu Problemen. Selbst wenn eine Applikation sich um die korrekte Darstellung von Emojis gekümmert hat, fallen non-ASCII-Buchstaben häufig doch noch durchs Raster - auch wenn man annehmen könnte, dass in Zeiten von UTF-8 so etwas nicht mehr vorkommen sollte. Und spätestens wenn eine Zeichenfolge von mehreren Systemen nacheinander verarbeitet wird, kommt es bei der Konvertierung immer wieder zu Fehlern.

Folgen

Okay, ein paar Zeichen werden nicht akzeptiert oder können nicht richtig dargestellt werden. Ist das wirklich so schlimm? Na gut, mit einem Konferenz-Badge, wo der Name nicht ganz passt, kann man sich vielleicht noch irgendwie arrangieren. Aber es kann tatsächlich auch größere Folgen haben.

• Paket kommt nicht an

• Offizielle Dokumente können nicht auf den richtigen Namen ausgestellt werden

• Flüge finden unter einem anderen Namen statt mit potenziellen Problemen bei der Kontrolle am Flughafen

• Der Impfnachweis wird nicht in der passenden App ausgegeben

• Visa-Anträge können nicht bearbeitet werden

Stéphanie bemerkt zum Ende hin: In einer globalisierten Welt, in der Menschen sich bewegen, ist es erforderlich, die Bedürfnisse und Anforderungen dieser Menschen über die von Datenbanken und 400 Jahre alten Druckern zu stellen.

Und was hat das jetzt mit SEO zu tun?

Einiges!

Denn wir wissen ja, dass die User Experience auch für Suchmaschinen wie Google sehr wichtig ist. Und auch in unserer täglichen Praxis gibt es einige konkrete Fälle, wo wir genau aufpassen sollten, dass und wie wir mit bestimmten Zeichen umgehen. Ein paar Beispiele:

• Keyword-Targeting bei Umlauten

• Invalide XML-Dateien mangels Einsatz von UTF-8

• Invalider Product-Feed, da Sonderzeichen nicht escaped

• Fehlerhafte Titles und Descriptions, die Google dazu bewegen, eigene Snippets zu bauen

• Kaputte URLs durch Probleme bei der Umwandlung

Und was ist Deine Erfahrung mit Buchstabensalat?

Als Johan und ich am Donnerstagabend über das ein oder andere Probleme eines News Publishers und seiner Sitemaps philosophierten, sind wir auf eine interessante Problematik gestoßen:

Der Publisher, eine regionale Tageszeitung, wurde in der Mitte des 20. Jahrhunderts gegründet und publiziert seine Artikel seit dieser Zeit, in dieser Tageszeitung. Dieses Newsarchiv ist auch online verfügbar.

Jetzt wird es spannend! Nehmen wir z. B. einen Artikel vom 03.03.1968, welches Datum würdest Du der URL in der Sitemap als LastMod geben? Das Datum als der Artikel im original publiziert wurde? Oder das Datum als der Artikel online verfügbar gestellt wurde?

Warum wir uns diese Frage stellen müssen? In der Analyse der Sitemaps unseres Kunden zeigten sich vermehrt Fehler mit ungültigen Datumswerten in der LastMod-Angabe. Als wir uns die Werte anschauten fühlte ich mich sofort wieder in den Informatikkurs "Informatik 1" zurückversetzt. In diesem Kurs ging es vor allem um Speicherverwaltung, unterschiedliche Datentypen und wie der Computer mit diesen unterschiedlichen Datentypen umgeht. So unterscheidet der Computer z.B. zwischen Datentypen für Zeichen und Datentypen für Zahlen. Mit Datentypen für Zahlen kann der Computer unter anderem Rechnen, also Variable A + Variable B = Ergebnis. Dies geht mit Datentypen für Zeichen nicht. Zusätzlich gibt es weitere Untertypen. Je nachdem aus welchen Wertebereichen ich Zahlen speichern muss: Der Datentype "Word" speichert auf einem 32 Bit- System Zahlenwerte zwischen 0 und 232-1. Den Datentype "Integer" kann ich hingegen nutzen, wenn ich auch negative Werte speichern möchte (Wertebereich: -231..231-1).

Was das alles mit unserem Artikel der Tageszeitung vom 03.03.1968 zu tun hat? Dazu muß ich Dir noch erklären, wie der Computer Datumswerte und speziell den 03.03.1968 speichert:

Viele Server im Internet arbeiten mit dem Betriebssystem Linux. Auf diesen Computersystemen werden Datumswerte als so genannter Unix-Timestamp gespeichert. Berechnet wird ein Datum einfach als Anzahl Sekunden seit dem 01.01.1970. Das Publikationsdatum unserer heutigen Newsletterausgabe würde also den Timestamp 1645511400 tragen. Nach dieser Logik ergibt der Timestamp für den 03.03.1968 den Wert -57805200000. Dies ist nach Linux- & Unix-Definition ein gültiger Wert. Jedoch scheint Google für die Verarbeitung des Datenfeldes "LastMod" ein "Word"-Datentype zu nutzen und kann hier keine negativen Werte akzeptiert. Das frühestmögliche Datum für die LastMod-Angabe einer URL kann damit der 01.01.1970 00:00:00 Timestamp 0 sein, bevor Google das Datum als fehlerhaft ausgibt.

Dies stellt Newspublisher mit Archiven und Artikeln, die vor dem 01.01.1970 erschienen sind, vor die Herausforderung, dass diese Publisher ggf. ein zusätzliches Datenfeld benötigen, um ein Publikationsdatum in einer Sitemap bereitstellen können.

Mit dieser These bewaffnet hatte ich dann am selben Abend noch eine Test-Sitemap auf einem privaten Projekt aufgesetzt und diese bei Google und Bing eingereicht. Ich wollte meine These bestätigen. Und siehe da: Bei Google lässt sich das erste valide Datum genau auf den 01.01.1970 legen, wohingegen Bing vorbildlich auch mit älteren Datumswerten vor dem 01.01.1970 umgehen kann.

In meinen Recherchearbeiten zu diesem Artikel bin ich dann wieder an eine Problematik erinnert worden, die mit dem Unix-Timestamp in Verbindung steht. Könnt Ihr Euch noch an das Jahr 1999 erinnern? Das Jahr 2000 stand bevor und die Welt hielt den Atem an, ob unsere Computer dieses Datum überstehen würden oder Raumstationen vom Himmel fallen, wir kein Geld mehr am Geldautomaten bekommen und die Welt untergeht. Alles Fragen, auf die man rückblickend schmunzeln kann.

Aber die Datumsthematik unseres Publishers hat Mal wieder gezeigt: Bei Datumsangaben kann man nie vorsichtig genug sein. Man weiß ja nie.