Algorithm Change Log for SEO: Preserve Event Provenance

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 typing of all classes in a public Google feed.

Trust / COI: About · Corrections. We sell SEO analysis workflows, so product references are a conflict of interest. The class counts below come from a desk parse of a public JSON feed, not a customer GSC export and not a ranking study.

Build an algorithm change log for SEO with typed records, stable identifiers, source timestamps, correction history, and explicit interpretation limits.

TL;DR

An algorithm change log for SEO is a typed, provenance-preserving feed. It keeps official incidents, documentation edits, product observations, and analyst hypotheses in separate classes so a later reader can see what kind of evidence a row is.

Direct answer: Build an algorithm change log for SEO so each row carries a source URL, a controlled type, and the retrieval clock. The 2026-09-14 Search Status payload mixed core, spam, serving, and Discover in one file. Typing those rows is the job. Collapsing them into “an update” is the failure.

On 2026-09-14 we fetched incidents.json and observed HTTP 200, 12,961 bytes, and ten objects. Reproduce the parse with curl and json.loads. Class labels in our table come from external_desc. They are not a Google enum.

What you will learn

• How the ten-row mix splits across four classes
• Why an algorithm change log for SEO stores incident count and mean duration as different series
• How the June 2026 spam permalink demonstrates one typed row
• Where documentation edits and hypotheses sit beside incidents
• Why the feed cannot establish site-level cause

What an algorithm change log for SEO records

Key definition: An algorithm change log for SEO is a maintained feed that distinguishes official incidents, documentation edits, product observations, and analyst hypotheses, and that keeps a stable identity plus a correction trail for each row. It is not a rumor firehose and it is not a core-only calendar.

We evaluate this algorithm change log for SEO as provenance work. The W3C PROV data model distinguishes entities, activities, derivations, and responsible agents. Those concepts fit a correction trail. They do not certify that Google published every ranking change, and they do not name the query that lost clicks.

Google’s crawler overview is a reminder that retrieval and ranking are different jobs. The public incident feed already splits Ranking and Serving products. An algorithm change log for SEO that collapses those products will later blame a ranking window for a serving outage.

InfiniSynapse supplies an API foundation for long-running feed and export tasks, but update dates remain facts drawn from Google sources. After a traffic drop, a user may upload the matching GSC export through an InfiniSynapse Server API task workspace so source records, joins, and reviewer notes remain traceable. The layer predicts nothing and guarantees no recovery.

Four classes in one provenance trail

The 2026-09-14 incident payload used four classes we assigned from the official descriptions: core, spam, serving, and Discover. A complete algorithm change log for SEO also has room for a fifth and sixth lane that the JSON will never ship: a documentation-edit row and a hypothesis row.

Those extra lanes matter to an algorithm change log for SEO because Google’s Search documentation updates page can change in the same week as a named incident. The help text is a different evidence class. Mixing it into the incident identity is how a doc edit becomes “Google rolled something.”

Official incidents versus documentation edits

An incident permalink is a status object with begin, end, and updates[]. A documentation edit is a help-center or developers page whose visible wording changed. Search Central documentation is the parent surface for many of those pages. The W3C PROV data model is the independent vocabulary this page uses when a later editor asks who derived a typed row. IANA’s JSON media type is the registry name for the feed bytes, not a ranking opinion. An algorithm change log for SEO stores both, under different types, with different keys.

A product observation is something you measured on your own property. A hypothesis is a sentence you are not yet willing to treat as a source fact. If those two types share a label with official incidents, an algorithm change log for SEO will teach consumers to treat your guess as Google’s announcement.

Observed ten-row mix on 2026-09-14

We typed the payload at our desk. It is not a customer case and not a market study. The sample size is the ten objects Google returned that morning. A later fetch can add, drop, or rewrite rows.

Hours are (end − begin) in UTC, then averaged inside the class. Mean duration is not impact. Incident count is not impact. An algorithm change log for SEO keeps both series so a briefing cannot hide a one-row Discover window behind a four-row spam count.

Figure: Two series from the same ten-row official feed, grouped by class. Count is how many objects arrived. Mean duration is elapsed time. Neither series is impact.

How we fetched incidents.json

curl -sS -D - -o incidents-2026-09-14.json \
  https://status.search.google.com/incidents.json

An algorithm change log for SEO should archive HTTP status, payload bytes, object count, class mix, and the poll clock next to the table. If tomorrow’s file has eleven objects, add a retrieval note. Do not quietly replace today’s ten.

We parse the saved bytes with json.loads and keep id as the incident identity. Daily polling that inserts a new row for the same id is a defect, not freshness.

Incident count versus mean duration

Spam is the most common class in this snapshot (four rows) and not the longest class by mean hours. Discover is the rarest class (one row) and the longest by mean hours (521.0). Serving is short on average because the 25 February 2026 disruption lasted 0.2 hours even though the October 2025 serving issue lasted 72.7 hours.

A typed algorithm change log for SEO that only plots count will make spam look like the whole story. One that only plots mean hours will make Discover look like the whole story. The chart holds both series because the feed holds both facts.

Eight of ten rows are SERVICE_INFORMATION with severity: low. Two serving rows are SERVICE_DISRUPTION with severity: medium. That distinction belongs on the row. A serving outage and a named ranking update are different products.

June 2026 spam as a typed row

The June 2026 spam incident is the worked example for one official row. Google’s description names a spam update. The observed window is 2026-06-24 16:00 UTC to 2026-06-26 17:00 UTC, 49.0 hours, two status updates, product Ranking, impact SERVICE_INFORMATION.

That permalink is enough for an algorithm change log for SEO to type the row as spam and to give it a stable identity. It is not enough to say a site was demoted. Google’s spam policies explain the policy surface that a spam-class row should be read against. Policy text still does not name your URLs.

An algorithm change log for SEO that copies only the month “June 2026” and drops the permalink has already lost the type. Another June event in the same file is a core, and a third June event does not exist in this snapshot. Month alone is not a class.

Fields that stay on the source object

Keep the page title, direct URL, assigned class, visible timestamps, timezone, retrieval date, product, and impact. The status dashboard documentation is the official human-readable twin of the JSON fields. An algorithm change log for SEO should store both the HTML wording you saw and the machine fields you parsed, because later summaries tend to replace Google’s sentence with a vendor nickname.

Fields the source will never name

The incident page will not list affected hosts, queries, or ranking factors. The June 2026 spam row therefore cannot establish why one template lost clicks. Where the source is silent, the typed feed stays silent or labels the sentence as analysis. Temporal overlap can prioritize review. Overlap does not prove causation.

How to type and identify a row

Typing is a source test. Identity is a key test. An algorithm change log for SEO that skips either test will duplicate rows or mislabel them.

Assign a controlled class first

Choose one of: official-core, official-spam, official-serving, official-discover, documentation-edit, product-observation, or hypothesis. Assign the class before publication. If you are unsure, use hypothesis. Do not default to “update.”

A reviewer can audit the class only when the source URL survives handoff. If the only stored field is a Slack nickname, the row is already untyped.

Stable identity across polls

Derive the record key from the source URL or the feed id, plus the type. The June 2026 spam id (YUX1peHev5a4fkxLDiUQ) is the identity for that official row. A second poll on 2026-09-15 that sees the same id is a refresh, not a new change.

An algorithm change log for SEO that mints a new key on every successful curl will invent a change history Google never published.

Observed time versus effective time

Observed time is when your feed saw the value. Effective time is the begin / end the source published. Store them independently. Retrieval on 2026-09-14 does not move the June spam window to September.

The status dashboard documentation already separates event time from the messages posted about the event. A typed algorithm change log for SEO should do the same. Crawler time is not event start.

Correction events and freshness

When Google edits a completion note, append a correction record: old value, new value, reason, and the new retrieval time. Do not overwrite the first observation. An algorithm change log for SEO that loses yesterday’s wording cannot reconstruct what consumers queried.

Expose last successful sync and the direct source link on every row. A stale cache that looks current is a provenance failure. An algorithm change log for SEO that returns an empty “no change” payload after a failed sync has converted an outage into a stillness claim.

Documentation-edit rows follow the same rule. If the Search documentation updates page later revises a paragraph, append a correction. Do not pretend the first wording never existed.

Failure modes that break provenance

Untyped stream

The warning sign is status incidents and documentation edits sharing one label. The corrective action is to require the controlled types. Keep that warning attached to the affected algorithm change log for SEO row so a summary cannot hide it.

Polling duplicates

The warning sign is every retrieval creating a new change. The corrective action is to deduplicate on source identity and event version. In an algorithm change log for SEO, resolving duplicates requires a documented correction, not a more confident attribution.

Silent overwrite

The warning sign is a source edit changing historical API output with no correction row. The corrective action is to append and to preserve the earlier observation. A second reviewer should reopen the permalink before anyone closes a finding that depended on the old wording.

Limits of a public typed feed

Source availability

A failed sync creates staleness. It must not create a no-change event. This limit constrains an algorithm change log for SEO even when every local calculation is correct. Publish the last successful retrieval beside the table.

The 2026-09-14 fetch is one successful poll. It is not a customer result. Anyone using the typed feed on a live property must attach their own export. The ten-row sample size cannot establish a site-level story.

Interpretation boundary

The feed reports publications and observations, not undisclosed algorithm mechanics. Spam-class rows should be read next to the spam policies page. They still do not prove that a template violated those policies. Core-class rows should be read next to the core-only changelog. They still do not prove that a URL moved because of that core.

Duration does not prove impact. Class mix does not prove that your vertical was in scope. The typed algorithm change log for SEO stops at the published object and the filters you can reopen.

Where the typed feed hands off

This page keeps typing and provenance. Adjacent jobs live on sibling pages:

Frequently Asked Questions

What is the difference between observed and effective time?

Observed time records when the feed saw a value. Effective time records when the source says the window applied. For an algorithm change log for SEO, those fields stay independent. Retrieval on 2026-09-14 does not rewrite a June begin. The answer claims no access to Google’s private ranking logic.

How should duplicate status rows be handled?

Use the source incident identity and append lifecycle updates to the same logical event. Treat this as an operational rule for the typed feed, not privileged visibility into Google’s private systems. Apply that answer within an algorithm change log for SEO only to the filters and period actually inspected.

Can analyst hypotheses appear in the feed?

Yes, but only under an explicit hypothesis type that cannot be confused with Google-authored facts. The typed algorithm change log for SEO conclusion is limited to inspected evidence and reveals no undisclosed Google signal.

What should an API return during a failed sync?

Return the last successful data with a stale indicator and error metadata, not an empty no-change response. Nothing in this algorithm change log for SEO answer assumes private knowledge of Google’s ranking logic.

Conclusion

Use an algorithm change log for SEO when the job is to keep every named class, plus documentation edits and hypotheses, under keys a reviewer can replay. The 2026-09-14 snapshot shows ten official objects, four incident classes, and a June 2026 spam permalink that types one row without proving site impact. Close the algorithm change log for SEO when the source URL, the class, the retrieval time, and the unresolved alternatives are all still visible. A typed row is more useful than an unsupported recovery claim.