Google Search Console’s 1969 Date Filter Bug: What to Do

If Google Search Console refused your custom date range and trapped the end date in 1969, you did not mistype the year. A temporary defect in the Performance report’s custom date selector caused the problem.

The useful response is to separate the broken control from the report you need. Built-in date presets continued to work, giving you a temporary reporting path while avoiding unsupported conclusions about traffic, rankings, or data loss.

Key takeaways

• The defect affected the custom date-range selector in Google Search Console’s Performance report.
• The selector preset the end date to 1969 and rejected dates later than December 31, 1969.
• The built-in 24 hours, 7 days, 28 days, 3 months, 6 months, 12 months, and 16 months filters remained available.
• The problem was fixed at about 9 a.m. ET on the same morning it appeared.

How to recognize the documented failure pattern

The strongest diagnostic clue was not simply that a custom report failed. It was the specific combination of an end date set to 1969 and a validation limit that prevented any later date.

The control returned the message "Date can’t be after 1969-12-31." If selecting a built-in range still produced a report, the behavior matched the known interface bug closely.

• Custom range fails with the 1969 limit: This matches the documented date-picker defect.
• A preset range loads normally: Use it as a temporary view, subject to its different reporting window.
• Preset ranges fail too: That falls outside the documented pattern. Do not assume the old custom-selector bug explains it.

That distinction matters. A precise error signature lets you avoid spending time investigating unrelated SEO implementations when the visible failure is in a reporting control.

Keep reporting with presets, but label the limitation

The available workaround was to leave the custom selector and choose one of the functioning presets: 24 hours, 7 days, 28 days, 3 months, 6 months, 12 months, or 16 months. Pick the smallest preset that contains enough history for the immediate decision in front of you.

A preset is not automatically an exact substitute for your intended dates. If you needed a campaign period, month-end comparison, migration window, or other fixed interval, changing the boundaries can change the result. Treat the preset output as provisional unless its dates match the period you meant to analyze.

1. Exit the broken custom date selector and open the nearest useful built-in range.
2. Record the preset name and when you retrieved the figures so another person can reproduce the view.
3. Label any shared numbers as provisional if the preset does not match the intended reporting window.
4. Avoid comparing that provisional window with an exact historical interval as though their boundaries were identical.
5. Once custom selection works, rerun the intended dates and replace the provisional figures in dashboards, reports, and decisions.

This preserves momentum without quietly changing the question your analysis was meant to answer.

Do not turn a date-picker error into an SEO incident

The 1969 message established that the interface was rejecting the requested end date. It did not, by itself, establish lost clicks, missing impressions, an indexing problem, a ranking decline, or damage to the site’s search visibility.

That means you should not change site code, structured data, canonical tags, robots directives, or sitemaps in response to this symptom alone. None of those changes repairs a date-picker validation error, and unnecessary production changes can create a real technical problem while you are reacting to a reporting one.

Keep stakeholder language equally precise. A useful status note would be: "Custom date selection is temporarily unavailable; preset views remain accessible, and exact-period analysis is pending." This states what you can verify without implying that organic performance changed.

What to verify after the fix

The known incident was fixed at about 9 a.m. ET that same morning. Once the selector is available, do not simply assume that a provisional preset report answers the original question.

1. Open the Performance report and enter the exact start and end dates you originally needed.
2. Confirm that the displayed range matches those dates before interpreting or exporting the results.
3. Rerun any analysis completed with a substitute preset.
4. Replace provisional numbers wherever they were shared, especially when decisions depend on exact period boundaries.

If the 1969 limit appears again, capture the report name, requested dates, exact error, time of occurrence, and whether each built-in preset works. That evidence will help distinguish a recurrence of the known custom-selector failure from a broader or different reporting problem.

Your next move is simple: retry the exact custom interval, verify its boundaries, and only then resume period-over-period analysis. The selector is part of the measurement workflow; it should not become evidence for an SEO conclusion that the report itself has not established.

References

• Search Engine Land — Google Search Console reporting date selector is broken