Wenn du in der Google Search Console regelmäßig mit Leistungsdaten arbeitest, kennst du wahrscheinlich diesen kleinen Moment: Du willst schnell einen Zeitraum prüfen, klickst den Datumsfilter an, setzt Start- und Enddatum – und erwartest, dass die Zahlen sauber geladen werden. Genau dieser sonst banale Arbeitsschritt hat zeitweise für Verwirrung gesorgt. Der Datumswähler im Leistungsbericht der Google Search Console funktionierte nicht richtig, genauer gesagt beim benutzerdefinierten Zeitraum.
Das Problem war auf den ersten Blick fast absurd: Das Enddatum sprang offenbar auf ein Datum rund um 1969 beziehungsweise 1970. Und wer versuchte, das Datum zu ändern, bekam eine Fehlermeldung in der Art: „Das Datum darf nicht nach dem 31.12.1969 liegen“. Für ein Tool, das moderne Suchdaten auswerten soll, ist das natürlich ein ziemlich schräger Rückfall in die Vergangenheit.
Aus meiner Erfahrung mit solchen Tools ist genau so etwas besonders lästig, weil es nicht nach einem dramatischen Ausfall aussieht. Keine große rote Warnung, kein Systemstatus, der dich vorbereitet. Stattdessen sitzt du da, willst kurz eine Analyse ziehen, und plötzlich blockiert dich ein Datumsfeld. Für SEO-Leute, Website-Betreiber oder Agenturen ist das mehr als nur ein kosmetischer Fehler. Wenn du gerade Reports vorbereitest, Traffic-Veränderungen prüfst oder einen Rückgang erklären musst, brauchst du zuverlässige Zeiträume. Punkt.
Was genau kaputt war
Betroffen war der Datumsfilter im Performance-Report der Google Search Console. Also jener Bereich, in dem du Klicks, Impressionen, durchschnittliche Positionen und CTR nach Zeitraum auswerten kannst. Die Standardoptionen funktionierten offenbar weiterhin. Das heißt: Du konntest vordefinierte Zeiträume wie letzte 24 Stunden, 7 Tage, 28 Tage, 3 Monate, 6 Monate, 12 Monate oder 16 Monate auswählen.
Der Fehler trat vor allem dann auf, wenn du einen benutzerdefinierten Datumsbereich auswählen wolltest. Genau dort wurde es merkwürdig. Das Enddatum war plötzlich auf ein historisches Datum festgesetzt. Mal wurde 1969-12-31 angezeigt, mal tauchte 1970-01-01 auf. Beides sind typische Daten, die man bei technischen Datumsfehlern schon mal sieht.
Warum gerade 1969 oder 1970? Ohne hier unnötig tief in Systemarchitektur abzutauchen: Viele Computersysteme rechnen Zeit intern ab einem festen Ursprungspunkt, der sogenannten Unix-Epoche. Diese beginnt am 1. Januar 1970. Wenn irgendwo eine Zeitangabe fehlt, falsch verarbeitet wird oder durch Zeitzonenverschiebungen verrutscht, können solche Daten entstehen. Das ist nicht neu. Wer länger mit Datenbanken, Tracking-Systemen oder APIs arbeitet, hat solche Ausreißer bestimmt schon gesehen. Trotzdem ist es etwas anderes, wenn das in einem zentralen Google-Tool passiert.
Das Kuriose war nicht nur, dass das falsche Datum angezeigt wurde. Entscheidend war: Du konntest es offenbar nicht vernünftig korrigieren. Beim Versuch, ein späteres Enddatum auszuwählen, erschien die Meldung, dass das Datum nicht nach dem 31. Dezember 1969 liegen dürfe. Und seien wir ehrlich: Für Suchleistungsdaten im Jahr 2026 ist das eine ziemlich nutzlose Einschränkung.
Warum der Fehler in der Praxis nervt
Auf dem Papier klingt es erst einmal wie ein kleiner UI-Bug. Ein kaputter Date Picker, na gut. Morgen ist er repariert, weiter geht’s. Aber im Alltag hängt an diesem kleinen Kalender mehr, als man vielleicht denkt.
Wenn du SEO ernsthaft betreibst, vergleichst du ständig Zeiträume. Du schaust dir an, ob ein Update Auswirkungen hatte. Du prüfst, ob eine technische Änderung die Indexierung oder die Klickzahlen beeinflusst hat. Du willst sehen, ob eine neue Landingpage anzieht oder ob ein Rückgang nur saisonal ist. Dafür brauchst du nicht immer Standardzeiträume. Sehr häufig brauchst du exakt zugeschnittene Bereiche: vor und nach einem Relaunch, die Woche nach einer Migration, den Zeitraum einer Kampagne, die Tage rund um ein Core Update oder einfach den Monat, den dein Kunde im Reporting sehen will.
Wenn der benutzerdefinierte Zeitraum nicht funktioniert, bist du plötzlich eingeschränkt. Die Standardfilter helfen dann zwar ein bisschen, aber sie treffen oft nicht den Zeitraum, den du wirklich brauchst. Und manchmal reicht „letzte 28 Tage“ eben nicht. Ich hatte schon Projekte, bei denen ein Unterschied von zwei Tagen entscheidend war, weil genau an einem Freitag ein Template ausgerollt wurde und am Montag die ersten Ranking-Veränderungen sichtbar wurden. Solche Dinge verschwimmen, wenn du nur grobe Zeitfenster nutzen kannst.
Besonders unangenehm wird es beim Reporting. Stell dir vor, du musst am Morgen Zahlen für ein Meeting ziehen. Der Kunde oder dein Team erwartet eine klare Einordnung. Du öffnest die Search Console, willst schnell den Zeitraum einstellen – und der Kalender hängt im Jahr 1969. Natürlich kannst du improvisieren. Vielleicht über Looker Studio, vielleicht über die API, vielleicht mit bereits gespeicherten Exporten. Aber das kostet Zeit. Und es gibt diesen leicht peinlichen Moment, in dem du erklären musst: „Das Tool funktioniert gerade nicht richtig.“
Solche Sätze hört niemand gern. Auch wenn du nichts dafür kannst.
Die Standardzeiträume waren offenbar nicht betroffen
Ein wichtiger Punkt: Die vordefinierten Zeiträume schienen weiterhin zu funktionieren. Das macht den Fehler etwas weniger kritisch, aber nicht harmlos. Du konntest also weiterhin grobe Leistungsdaten abrufen, sofern dir die angebotenen Fenster ausreichten. Für viele schnelle Checks war das vermutlich genug.
Wenn du nur wissen wolltest, wie sich deine Seite in den letzten sieben oder 28 Tagen entwickelt hat, konntest du wahrscheinlich weiterarbeiten. Schwierig wurde es erst, sobald du präziser werden wolltest. Und genau das ist im professionellen SEO-Alltag nun mal ständig der Fall.
Ich finde solche Fehler deshalb so tückisch, weil sie leicht unterschätzt werden. Ein komplett ausgefallenes Tool erkennt jeder sofort. Ein teilweise defekter Filter dagegen führt manchmal dazu, dass Menschen sich Workarounds bauen, Zahlen falsch vergleichen oder schlicht Zeit verlieren. Und Zeitverlust ist in Reporting-Prozessen oft der eigentliche Schaden.
Der Ablauf: kaputt, repariert, wieder kaputt, wieder repariert
Nach den beobachteten Meldungen war der Fehler zunächst am 13. Oktober 2026 sichtbar. Das Problem wurde entdeckt, in der SEO-Community diskutiert und offenbar auch von anderen bestätigt. Manche sahen das Enddatum bei 1969, andere bei 1970. Das deutet darauf hin, dass es nicht nur ein lokales Anzeigeproblem auf einem einzelnen Rechner war.
Am selben Morgen wurde der Fehler anscheinend behoben. Gegen 9:10 Uhr galt der Datumswähler wieder als funktionierend. Damit hätte die Sache erledigt sein können. Ein kurzer Ausrutscher, ärgerlich, aber nicht weltbewegend.
Nur blieb es nicht dabei. Am nächsten Tag, dem 14. Oktober 2026, war der Fehler offenbar wieder da. Wieder war der benutzerdefinierte Datumsfilter betroffen, wieder machte der Date Picker Probleme. Solche Rückfälle sind für Nutzer besonders frustrierend. Denn sobald ein Bug einmal als „repariert“ gilt, verlässt man sich darauf. Wenn er dann zurückkommt, wirkt das System instabil – auch wenn im Hintergrund vielleicht nur ein Rollout, ein Cache-Problem oder ein schrittweiser Fix die Ursache ist.
Später an diesem Vormittag, gegen 9:45 Uhr, wurde der Date Picker erneut als repariert gemeldet. Die Formulierung „für jetzt“ passt hier ziemlich gut. Bei solchen Bugs bleibt immer ein kleiner Zweifel, ob das Problem wirklich dauerhaft weg ist oder nur gerade nicht sichtbar.
Was du daraus mitnehmen solltest
Der wichtigste praktische Punkt lautet: Wenn du an einem solchen Tag ungewöhnliche Probleme in der Search Console siehst, solltest du nicht sofort deine Website verdächtigen. Manchmal liegt der Fehler schlicht im Tool.
Das klingt banal, aber ich sehe in der Praxis immer wieder, dass Menschen bei Datenpannen sofort nervös werden. Plötzlich wird geprüft, ob die robots.txt geändert wurde, ob Canonicals kaputt sind, ob Tracking fehlt, ob Google ein Update fährt. Alles sinnvoll – aber wenn die Oberfläche selbst spinnt, solltest du erst einmal ruhig bleiben.
Bei diesem konkreten Problem ging es nicht darum, dass deine Leistungsdaten verschwunden oder falsch berechnet waren. Es ging um den Zugriff beziehungsweise die Auswahl eines Datumsbereichs in der Oberfläche. Das ist ein Unterschied. Die Daten können im Hintergrund völlig okay sein, während das Interface dir Unsinn anzeigt.
Natürlich weiß man das in dem Moment nicht mit Sicherheit. Deshalb hilft ein einfacher Gegencheck:
Teste zuerst einen vordefinierten Zeitraum. Wenn „letzte 7 Tage“ oder „letzte 28 Tage“ funktionieren, aber der benutzerdefinierte Zeitraum nicht, spricht viel für einen Fehler in der Bedienoberfläche. Prüfe außerdem, ob das Problem in einem anderen Browser oder Inkognito-Fenster ebenfalls auftritt. Nicht, weil das immer die Lösung ist, sondern weil du damit lokale Ursachen zumindest grob ausschließen kannst.
Wenn du Zugriff auf die Search Console API oder ein angebundenes Dashboard hast, kann auch dort ein Blick helfen. Läuft der Datenabruf dort normal, ist das ein weiteres Zeichen dafür, dass nicht die Datenbasis selbst betroffen ist.
Warum 1969 und 1970 bei Datumsfehlern immer wieder auftauchen
Der kleine Ausflug in die Technik lohnt sich, weil solche Fehler immer wieder vorkommen. Das Jahr 1970 ist für viele Systeme eine Art Nullpunkt. Genauer gesagt startet die Unix-Zeit am 1. Januar 1970 um 00:00:00 UTC. Viele Programme speichern Zeitpunkte als Sekunden oder Millisekunden relativ zu diesem Startpunkt.
Wenn nun ein Wert leer ist, falsch interpretiert wird oder statt eines echten Datums eine Null in die Berechnung rutscht, erscheint häufig der 1. Januar 1970. Je nach Zeitzone kann daraus auch der 31. Dezember 1969 werden. Wenn du westlich von UTC rechnest, kann der Zeitstempel null lokal noch am Vorabend liegen. Dann steht da plötzlich 1969.
Man kann sich das ein bisschen vorstellen wie einen Kilometerzähler, der nicht weiß, wo die Fahrt beginnt, und deshalb auf den Nullpunkt springt. Nur dass dieser Nullpunkt bei Datumswerten eben nicht „heute“ ist, sondern Anfang 1970. Für Entwickler ist das oft ein bekanntes Muster. Für normale Nutzer wirkt es eher wie ein schlechter Scherz.
Dass dieser Fehler ausgerechnet beim Enddatum auftauchte, ist interessant. Es könnte theoretisch bedeuten, dass ein Standardwert für das Enddatum nicht korrekt geladen wurde, dass eine Validierung falsch arbeitete oder dass im Zusammenspiel zwischen Oberfläche und Kalenderkomponente ein Datum als ungültig eingestuft wurde. Sicher sagen lässt sich das von außen natürlich nicht. Aber die Symptome passen zu einem klassischen Problem bei der Verarbeitung von Zeitstempeln.
Was ich daran bemerkenswert finde: Der Fehler blockierte offenbar nicht jedes Datum, sondern machte vor allem den benutzerdefinierten Bereich unbrauchbar. Das spricht eher für ein Problem in einer bestimmten Funktion als für einen kompletten Ausfall des Performance-Reports.
Wie du dich bei solchen GSC-Bugs verhalten kannst
Du kannst solche Fehler nicht verhindern. Die Search Console ist ein externes Tool, und selbst große Plattformen haben Bugs. Was du aber tun kannst: deine Arbeitsweise so bauen, dass dich ein kurzfristiger Ausfall nicht komplett lahmlegt.
Wenn du regelmäßig Reports erstellst, lohnt es sich, wichtige Daten nicht erst fünf Minuten vor dem Meeting zu ziehen. Ja, das klingt nach Kalenderweisheit, aber es rettet einem manchmal den Vormittag. Exportiere relevante Leistungsdaten frühzeitig, besonders wenn es um Monatsberichte, Migrationen oder größere Analysen geht.
Ich würde außerdem nie nur auf eine einzige Ansicht vertrauen. Die Search Console-Oberfläche ist gut für schnelle Analysen, aber für wiederkehrende Auswertungen sind zusätzliche Wege sinnvoll. Ein Dashboard, ein regelmäßiger API-Export oder zumindest gespeicherte CSV-Dateien können enorm helfen. Nicht, weil du ständig Ausfälle erwarten musst. Sondern weil du dann gelassener bleibst, wenn einer passiert.
Wichtig ist auch: Dokumentiere auffällige Tool-Probleme. Wenn du an einem Tag keine benutzerdefinierten Zeiträume ziehen konntest, schreib es dir kurz auf. Gerade bei späteren Auswertungen kann das helfen. Sonst fragst du dich Wochen später, warum ein Report ein anderes Zeitfenster nutzt oder warum bestimmte Daten fehlen.
Keine voreiligen Schlüsse aus fehlenden Daten ziehen
Ein kaputter Datumsfilter kann dazu führen, dass du versehentlich andere Zeiträume vergleichst als geplant. Das passiert schneller, als man denkt. Du willst eigentlich den 1. bis 13. Oktober prüfen, landest aber bei den letzten 28 Tagen, weil das eben noch funktioniert. Dann vergleichst du diese Daten vielleicht mit einem früheren festen Zeitraum – und plötzlich sehen Trends anders aus.
Deshalb: Wenn der benutzerdefinierte Filter spinnt, markiere deine Auswertung gedanklich als eingeschränkt. Nutze Standardzeiträume nur für grobe Orientierung, nicht für harte Schlussfolgerungen. Gerade bei SEO-Daten sind Zeiträume extrem wichtig. Ein Wochenende mehr oder weniger kann die Klickkurve verändern. Saisonale Peaks, Feiertage oder Kampagnenstarts ebenfalls.
Ich sage Kunden in solchen Situationen lieber ehrlich: „Die Oberfläche hatte heute ein Problem, ich liefere die genaue Auswertung nach.“ Das ist sauberer, als mit halbgaren Zahlen zu arbeiten. Meistens verstehen Menschen das, solange du transparent bist.
Was der Vorfall über die Abhängigkeit von Tools zeigt
Der Bug ist klein, aber er erinnert an etwas Größeres: Viele SEO-Prozesse hängen stark an wenigen zentralen Plattformen. Die Google Search Console ist dabei eines der wichtigsten Werkzeuge überhaupt. Sie zeigt dir keine vollständige Wahrheit, aber sie ist für organische Suche oft die direkteste Datenquelle, die du bekommst. Wenn dort etwas klemmt, merkt man sofort, wie abhängig man geworden ist.
Das ist nicht zwangsläufig schlecht. Die Search Console liefert wertvolle Daten, kostenlos und direkt aus Googles Systemen. Aber du solltest sie nicht als unfehlbar behandeln. Manchmal sind Daten verzögert. Manchmal ändern sich Darstellungen. Manchmal gibt es Interface-Bugs. Und manchmal ist eben ein Kalender plötzlich im Jahr 1969 gefangen.
Aus Expertensicht ist die richtige Haltung eine Mischung aus Vertrauen und Skepsis. Vertraue dem Tool genug, um damit zu arbeiten. Sei skeptisch genug, um bei seltsamen Signalen gegenzuprüfen. Diese Balance ist im SEO ohnehin wichtig. Nicht jede Kurve ist ein Rankingproblem. Nicht jeder Rückgang ist ein Algorithmus-Update. Und nicht jede Fehlermeldung bedeutet, dass mit deiner Website etwas nicht stimmt.
Bei diesem Datumsfehler war der Kern recht klar: Der benutzerdefinierte Datumsbereich im Performance-Report war zeitweise nicht zuverlässig nutzbar. Die Standardzeiträume funktionierten offenbar weiter. Das Problem wurde zunächst behoben, trat dann erneut auf und wurde wieder repariert.
Praktische Empfehlung für deinen Alltag
Wenn du selbst mit der Google Search Console arbeitest, würde ich aus diesem Vorfall drei Dinge mitnehmen.
Erstens: Prüfe bei merkwürdigen Anzeigen immer zuerst, ob das Problem reproduzierbar ist. Anderer Browser, anderer Account, anderer Zeitraum. Dauert zwei Minuten und verhindert manche falsche Diagnose.
Zweitens: Halte für wichtige Reports einen Ausweichweg bereit. Das kann ein API-basierter Export sein, ein Looker-Studio-Report oder schlicht ein regelmäßiger Download wichtiger Properties. Es muss nicht perfekt sein. Hauptsache, du bist nicht komplett blockiert, wenn die Oberfläche einen schlechten Tag hat.
Drittens: Ziehe aus einem kaputten Interface keine inhaltlichen SEO-Schlüsse. Wenn der Date Picker falsche Grenzen setzt, ist das ein Bedien- oder Systemfehler, kein Signal über deine Sichtbarkeit. Das muss man sich manchmal bewusst sagen, besonders wenn gerade ohnehin viel los ist.
Am Ende war dieser Vorfall kein Hinweis auf ein großes SEO-Problem, sondern ein klassischer, wenn auch nerviger Tool-Bug. Für den Arbeitsalltag zeigt er aber sehr schön, wie wichtig saubere Zeiträume in der Analyse sind. Ein Kalenderfeld wirkt unscheinbar. Doch wenn es ausfällt, merkst du erst, wie viel daran hängt.
Die gute Nachricht: Der Fehler wurde zwischenzeitlich behoben. Trotzdem lohnt es sich, bei künftigen Auswertungen aufmerksam zu bleiben. Wenn dir in der Search Console plötzlich Daten aus den Jahren 1969 oder 1970 begegnen, liegt das sehr wahrscheinlich nicht an deiner Website – sondern an einem technischen Schluckauf im Datumsfeld.
