Google Core Update Changelog: Verify Every Official Date

By William Zhu · Cofounder, InfiniSynapse · Published: 2026-09-08 · Last updated: 2026-09-14 · Last verified: 2026-09-14 · Reviewed by the InfiniSynapse Data Team.

Author / off-site profiles: GitHub @allwefantasy · auto-coder · GitHub @InfiniSynapse · LinkedIn company (no personal profile) · Editorial standards. No personal LinkedIn or vendor badge.

Reviewed by: InfiniSynapse Data Team · method review 2026-09-14. First-party filter of core-labeled objects from a public Google feed.

Trust / COI: About · Corrections. We sell SEO analysis workflows, so product references are a conflict of interest. The three-row table below is a desk filter of a public JSON feed, not a customer GSC export and not a ranking study.

Maintain a Google core update changelog from official incident records, preserve rollout milestones and provenance, and keep site-impact inference separate.

TL;DR

A Google core update changelog is a core-only ledger of named Search Status incidents. It stores the official title, permalink, start, end, and retrieval time. It drops spam, Discover, and serving rows even when those rows arrived in the same JSON payload. Non-core rows for September, including the empty confirmed list in google algorithm updates september 2026, stay off this ledger.

Direct answer: Keep a Google core update changelog as an evergreen list of core-labeled incident URLs you can reopen. The 2026-09-14 feed supplied three cores. Older official permalinks can still exist and still be missing from that payload. Overlap with a Search Console window can prioritize review. Overlap cannot prove that a core moved one URL.

On 2026-09-14 we fetched incidents.json and observed HTTP 200, 12,961 bytes, and ten objects. Only three of those objects used a core label. Reproduce the filter with curl and json.loads; do not treat derived hours as impact.

What you will learn

• Which three cores this snapshot actually shipped
• Why a Google core update changelog must keep permalinks that the latest poll omitted
• How duration hours and status-update counts stay separate series
• Where rumor weeks and mixed-class rows get rejected
• Why the ledger cannot establish site-level cause

What a Google core update changelog records

Key definition: A Google core update changelog is a maintained table that admits only incidents Google named as a core update, plus the retrieval metadata that makes those rows replayable. It is not a volatility calendar and it is not a mixed-class status dump.

We evaluate this Google core update changelog as a filter, not as a forecast. Google’s ranking systems guide describes several ranking systems and does not turn every weekly wobble into a named core. Wikipedia’s note on a changelog is the independent reminder that a ledger records published revisions, not every internal experiment. The Google core update changelog copies that boundary: if the source page does not say core, the row stays out.

The W3C PROV-O recommendation names entities, activities, and agents. That vocabulary helps a reviewer see who retrieved which permalink. It does not certify Google’s publication set and it does not score recovery. A Google core update changelog can borrow those labels without pretending PROV-O reviewed the feed.

InfiniSynapse can store an uploaded Search Console export in an InfiniSynapse Server API task workspace. The workspace keeps the filters you chose. It does not become a core oracle and it does not score recovery.

Official core rows versus rumor weeks

Each core object we parsed on 2026-09-14 exposed machine fields such as id, external_desc, begin, end, and uri. Those are observed fields. “This core crushed our category” is not one of them.

A social spike in the same week is a side note. It must not inherit the official begin time. The Google core update changelog can store that note in a non-official column. It cannot promote the note into a core row.

Why a ten-object feed is not a complete history

The machine-readable feed is a current window, not an archive of every core Google has ever named. Ten objects on one morning is the sample size of the poll, not the lifetime of Search. A Google core update changelog that treats the latest payload as the full chronology will delete still-valid permalinks the next time Google trims the JSON.

That limit is the point of this page. We run the filter against what arrived. We also keep older official URLs that a reviewer can still open, labeled as not in this snapshot.

Observed core rows on 2026-09-14

We ran this filter at our desk. It is not a customer case and not a market study. The sample size is the three core objects inside the ten-object payload Google returned that morning. A later fetch can add, drop, or rewrite rows.

Class is our label from external_desc, not a Google enum. Hours are (end − begin) in UTC. Updates are the length of the updates array. None of those derived columns measure traffic. The other seven objects in the same payload were spam, serving, or Discover and do not enter a Google core update changelog.

Figure: Two series from the three core rows in the 2026-09-14 feed. Duration is elapsed time. Updates are message count. Neither series is impact.

How we fetched and filtered incidents.json

curl -sS -D - -o incidents-2026-09-14.json \
  https://status.search.google.com/incidents.json
# core filter: external_desc contains "core update" → 3 rows

A Google core update changelog should sit next to the HTTP status, the byte count, the object count, the core count, and the poll date. If a later file returns two cores or four cores, write a retrieval note. Do not erase the three-row snapshot.

We parse the saved bytes with json.loads and keep the raw begin / end strings. Derived hours are a second column. They do not replace the source timestamps.

Duration hours versus status-update count

The longest core in this snapshot is the December 2025 window at 433.6 hours. The shortest is the May 2026 window at 285.0 hours. March 2026 sits between them at 292.0 hours. All three rows shipped two status updates. A long window is not a large ranking change. A short window is not a small one.

The chart therefore plots two series on purpose. A Google core update changelog that collapses those series into “big core” language has left the method.

All three cores are SERVICE_INFORMATION with severity: low. That is an observed product label, not a traffic verdict. The Google core update changelog stores it so a later briefing cannot invent a disruption grade Google did not publish.

Permalinks that sit outside this snapshot

A useful Google core update changelog is larger than the latest JSON. Official incident pages can remain open after they drop out of incidents.json. Those URLs stay in the Google core update changelog with a snapshot flag, not with a fabricated begin copied from memory.

This page keeps two such permalinks because earlier research already cited them and because today’s ten-object feed did not return them. Their absence does not prove Google unpublished the events. It only proves they were not in this payload.

June 2025 core still citable

The June 2025 core incident remains a reopenable official page. It was not one of the ten objects observed on 2026-09-14. A Google core update changelog should retain the URL, the retrieval date of the first citation, and a note that the row is outside this snapshot.

Do not invent hours for that row from a screenshot you no longer have. If you need duration, reopen the page, copy the timestamps you see that day, and append a new retrieval. The older permalink is evidence that the feed is incomplete. It is not a license to guess.

March 2025 core still citable

The March 2025 core incident is the second kept URL that today’s poll omitted. Treat it the same way: official, citable, and not in this snapshot. A reviewer who only diffs the latest JSON will miss it. A reviewer who opens the permalink will not.

Leaving those two rows visible is how a Google core update changelog stays honest about selective publication. Hiding them would make the ten-object feed look like a complete history.

How to admit a core row

Admission is a label test on a URL you can reopen. If Google did not name the event a core update on that page, the row stays out of the official Google core update changelog.

Required core label on the source page

Paste the incident permalink. Read the title and external_desc. The word core must appear as Google’s name for the event, not as your nickname for a bad week. Spam, Discover, serving, and rumor rows belong on the broader algorithm change log for SEO, not here.

A Google core update changelog that absorbs the August 2026 spam window because “it felt like a core” is no longer a changelog. It is a mood board.

Timestamp offsets and derived hours

Keep the source offset. Compute UTC hours in a derived column. RFC 3339 is the timestamp profile we used when converting begin and end. Offsets stay on the source fields. A Google core update changelog that rounds May 2026 to “late spring” will manufacture overlap the feed never claimed.

If two retrievals disagree on a completion note, keep both and label the newer one as a correction. Do not overwrite the first retrieval.

Immutable permalink plus retrieval date

The permalink is the primary key. The retrieval date is the provenance stamp. Together they let a second reviewer reopen the same page and see whether Google later edited the copy. The W3C PROV-O recommendation calls that an entity plus an activity. The Google core update changelog only needs the habit: never replace a permalink with a blog nickname.

Corrections without silent rewrite

Google can edit a completion sentence after you first saved the row. Append a correction line that points at the prior value. Do not patch the original cell until the correction line exists.

A Google core update changelog that silently rewrites history cannot be replayed. The next editor will not know which hours were observed on 2026-09-14 and which hours arrived later.

If the feed later drops a core you already admitted, keep the row and mark it absent from the new snapshot. Deletion is a publication change, not proof that the event never happened. A ledger that deletes first and asks later cannot be replayed.

Failure modes that contaminate a core ledger

Mixed-class rows

The warning sign is a spam or Discover object sitting in a core-only table because it arrived in the same file. The correction is rejection. Move the row to the typed feed. Keep the rejection note on the Google core update changelog so a later summary cannot hide it.

The 2026-09-14 payload made this easy to get wrong: four spam rows, two serving rows, and one Discover row sat beside the three cores. Duration on the August 2025 spam window (639 hours) is longer than any core in the snapshot. Length is not a core label.

Month-only labels

The warning sign is a cell that says “March 2026” with no begin or end. The correction is to reopen the permalink and copy the timestamps. In a Google core update changelog, a month label is a display hint, not a join key.

Rumor backfill

The warning sign is an empty week filled with a vendor heatmap so the chronology looks continuous. The correction is to leave the week blank. A blank week means no named core was in the sources you hold. It does not prove ranking was frozen.

Limits of a named-core ledger

Named-event scope

Google describes smaller ranking changes that never become a named core. A quiet stretch in the Google core update changelog is a retrieval result, not a stillness certificate. The ranking systems guide already says several systems operate continuously. Publish that caveat beside any empty date.

This snapshot cannot establish that those quieter changes were small, large, or relevant to one site. The sample size is three named cores plus two older permalinks, not the unpublished remainder.

No site-impact field

The feed never lists affected URLs, industries, or queries. The three-row sample therefore cannot establish why one page lost position. That limit survives even when every hour calculation is correct. Duration does not prove impact, and a matching GSC dip does not prove that Google caused the dip.

The three-row file is also not a customer result. No property export sat beside this poll. Anyone who later attaches a Google core update changelog to a live host has to bring their own preserved filters; our desk file has none.

Where the ledger hands off

This page keeps the core-only admission job. Adjacent jobs live on sibling pages:

Frequently Asked Questions

Why exclude spam updates from this changelog?

Because the page promises a core-only ledger. Mixing classes weakens joins and reader expectations. A Google core update changelog that absorbs spam rows can no longer tell a reviewer which window was a core. The answer claims no access to unpublished ranking logic.

What if completion is not posted yet?

Keep the row open and append the completion message when Google publishes it. Mark the window as open in the Google core update changelog. A briefing written mid-rollout is provisional. The May 2026 core in this snapshot ran 285 hours; day-two copy was not a closing note.

Should duration be rounded to days?

Store source timestamps first. A rounded display value can be derived without replacing them. Rounding “433.6 hours” to “eighteen days” is fine for a slide. It is not fine as the stored field in a Google core update changelog.

Can the ledger state which industries lost?

Not from the incident record alone. Industry impact requires separate, disclosed data. The three cores observed on 2026-09-14 name no verticals. Nothing in this answer assumes private knowledge of Google’s ranking logic.

Conclusion

Use a Google core update changelog when the job is to keep core-labeled permalinks, milestones, and retrieval notes without mixing in every object from the latest feed. The 2026-09-14 snapshot shows three official cores, two older permalinks outside that payload, and a hard split between duration and impact. Close the Google core update changelog when the Google fact, the snapshot flag, and the unresolved alternatives are all still visible. A bounded row is more useful than an unsupported recovery claim.