Daily SEO Note — September 27, 2026: The September Spam Update Is Still Rolling
This edition covers the 24 hours to 09:00 UTC on Sunday, September 27, 2026. Both tracks are honest about a quiet weekend: no new primary-source announcement landed on either the editorial or the engineering side in that window. What carries the day is the state of a rollout that is still in flight, plus two changes from Thursday, September 24 that most teams have not yet acted on. Every item below is dated to its primary source, and the rollout status is stated as the source states it.
1. SEO for Content Writers
The single most consequential editorial fact today is not a new announcement. It is that the September 2026 spam update is still rolling out. Google logged it once, on September 24 at 16:15 UTC, said it applies globally and to all languages, and warned the rollout may take up to two weeks. As of this morning the incident has no end time and no follow-up entry, so any ranking movement you saw on Saturday or Sunday sits inside an unfinished rollout and is not yet a result you can read.
The September 2026 spam update is mid-rollout, and that changes how you read your own analytics
What changed: Google released the September 2026 spam update globally, across all languages, and it has not been marked complete. Who it affects: all content, though spam updates bite hardest on sites with thin, scaled, or reputation-borrowed pages. The rollout status on the Search Status Dashboard is still open, with the original entry as the only update.
What to do differently in your next article: nothing reactive. A spam update in progress is the worst possible moment to rewrite, consolidate, or prune based on a few days of movement, because the position you are optimizing against is not final. Keep publishing to your normal standard and keep a dated log of what moved, so that when Google closes the incident you can compare a stable before and after rather than guessing mid-flight.
What to stop doing: stop treating day-to-day volatility this week as a verdict on individual articles. And if any part of your output relies on practices named in the spam policies — scaled content abuse, site reputation abuse, or expired domain abuse — stop shipping it now rather than waiting to see whether this particular update catches it. Those policies are enforceable independently of any single update.
Search Console can now show you which content wins image-led and camera-led searches
On Thursday, September 24, Google announced web multimodal Search performance reporting in Search Console. A new multimodal search type filter appears in the Search performance report and in the Generative AI features report. The data covers searches made with Lens, Circle to Search on Android, image uploads to Google Search, and the Chrome right-click "Search this image" option. Google states the integration is rolling out globally starting that day, and that you will see the metrics only if your site already receives that traffic.
Who it affects: any vertical where people point a camera at a thing instead of typing its name — product, plant and animal identification, recipes and food, fashion, parts and hardware, travel landmarks, medical and cosmetic visual queries. For text-only explainer content, this will likely stay empty, and that is a finding too.
What to do differently in your next brief: before you outline, open the performance report, apply the multimodal filter, and export. Treat the queries you find there as a separate intent class, because a camera query is a "what is this and what do I do about it" question, not a keyword. If a page earns multimodal impressions with poor CTR, the fix is usually an image that matches what the camera actually sees plus a direct answer in the opening lines, not more prose.
Video credit is now an explicit structured-data field, which makes your creator byline a search asset
Google's documentation changelog records a September 24 update adding the creator property to VideoObject and clarifying which interaction types are supported. The property is recommended rather than required, and when you name a person or organization you must supply either a name or an alternate name, with an optional URL to a page that uniquely identifies them.
Who it affects: one content type — anything with video on the page. The editorial consequence is small but real: the person or team who actually made the video now has a named, machine-readable slot, and the optional URL wants to point at a profile or author page that genuinely identifies them.
What to do differently: when you commission or embed video, capture the creator's name and a stable profile URL as part of the brief, the same way you already capture an author byline. Hand both to whoever implements the markup. What to stop doing: stop leaving video credit as a line of on-screen text or a caption only, where it cannot be read as a credential signal.
Unconfirmed: weekend chatter about Discover traffic
Community discussion over the weekend included reports of Discover traffic being throttled, alongside ranking volatility noted on September 23 and 24. Google has confirmed nothing about Discover specifically, and there is no Discover entry on the Search Status Dashboard. Treat this as unconfirmed, do not act on it, and note that the open spam update is a sufficient explanation for movement this week. It is excluded from the checklist below for that reason.
Apply to your next brief
- Freeze reactive rewrites and prunes until Google marks the September 2026 spam update complete; log what moves instead.
- Audit any remaining scaled-content, site-reputation, or expired-domain practices now, independently of this update.
- Add one step to every brief: check the new multimodal filter in Search Console and export it before outlining.
- For camera-led topics, lead with an identification answer and an image that matches what a camera would capture.
- Collect a creator name plus a stable profile URL for every commissioned or embedded video.
- Keep a dated before-and-after record this week so the post-rollout comparison is against stable data.
2. SEO for Developers
No framework, spec, or tooling release in the 24 hours to 09:00 UTC on September 27 changed anything SEO-relevant. The one thing worth an engineer's attention is a gap rather than a release: Search Console's new multimodal reporting exists in the interface, but the Search Analytics API enum has not been extended to match, so every automated reporting pipeline is currently blind to it.
Search Console's multimodal data is UI-only — your API pipeline cannot see it
Google's September 24 announcement describes a new multimodal search type filter in the Search performance report, and points you at the Export button to analyze the data elsewhere. The Search Analytics API query reference still documents exactly six values for the type dimension: web, image, video, news, discover, and googleNews. There is no documented multimodal value.
Non-breaking, but with a quiet symptom if ignored: nothing in your pipeline errors, and no dashboard turns red. You simply keep reporting web, image, and video totals and never notice that a distinct, growing query class is not represented among the types you request. Teams that report organic performance purely from the API will under-describe what is happening, and will have no baseline when the enum eventually appears.
The setting to change is your reporting job's list of requested types, and the honest fix today is documentation plus a manual export rather than code. Keep requesting the six documented values, and add a recurring manual export of the multimodal filter until Google documents an API value. If you script against the type dimension, pin the list explicitly instead of inferring it, so that the day a seventh value is documented you add it deliberately.
#!/usr/bin/env bash
# Search Analytics API: only these six `type` values are documented.
# https://developers.google.com/webmaster-tools/v1/searchanalytics/query
# Multimodal is NOT among them as of 2026-09-27 - export it from the UI.
set -euo pipefail
SITE="sc-domain:example.com"
TOKEN="$(gcloud auth print-access-token)"
for TYPE in web image video news discover googleNews; do
curl -sS -X POST \
"https://searchconsole.googleapis.com/webmasters/v3/sites/$(printf %s "$SITE" | jq -sRr @uri)/searchAnalytics/query" \
-H "Authorization: Bearer ${TOKEN}" \
-H "Content-Type: application/json" \
-d "{
\"startDate\": \"2026-09-20\",
\"endDate\": \"2026-09-26\",
\"dimensions\": [\"query\"],
\"type\": \"${TYPE}\",
\"rowLimit\": 25000
}" \
-o "out/sc-${TYPE}.json"
doneVideoObject gains a creator property and a clarified interactionStatistic
Dated September 24 in the Google Search documentation changelog, the VideoObject reference now documents a creator property and spells out the supported interaction types for interactionStatistic: WatchAction for views, LikeAction for likes or upvotes, CommentAction for comments, and ShareAction for reshares.
Non-breaking and additive. creator is recommended, not required, so existing valid markup stays valid and no rich result is lost by ignoring this. The symptom of ignoring it is only a missed opportunity: you leave a documented, machine-readable credit and engagement signal unpopulated. If you already emit interactionStatistic with an interactionType outside those four, that value is simply not among the supported ones.
The file to change is wherever you emit video JSON-LD — a template partial, or the object your framework serializes into a script tag. When you set creator, supply name or alternateName, and prefer a url that resolves to a real profile or author page. Only publish interaction counts you can actually source; do not synthesize them.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "Replacing a Thermostat Housing Gasket",
"description": "A step-by-step teardown filmed in our own workshop.",
"thumbnailUrl": ["https://example.com/img/gasket-16x9.jpg"],
"uploadDate": "2026-09-27T09:00:00+00:00",
"duration": "PT8M14S",
"contentUrl": "https://example.com/video/gasket.mp4",
"creator": {
"@type": "Person",
"name": "Oday Bakkour",
"url": "https://example.com/authors/oday-bakkour"
},
"interactionStatistic": [
{
"@type": "InteractionCounter",
"interactionType": "https://schema.org/WatchAction",
"userInteractionCount": 18422
},
{
"@type": "InteractionCounter",
"interactionType": "https://schema.org/LikeAction",
"userInteractionCount": 947
}
]
}
</script>Next.js shipped canaries only — nothing to promote to production
The only releases in the window on the Next.js repository were prereleases: v16.4.0-canary.49 at 21:04 UTC and v16.4.0-canary.50 at 23:44 UTC on September 26, following canary.46 through canary.48 on September 25. Their notes cover prerelease security upgrade limits, Turbopack webpack loader work, facade splits, a fix for Server Actions hanging after navigation to PPR pages, and cache node and route tree refactoring.
There is no stable release here, so the correct action is none. Canary is not a channel to put in front of Googlebot: the cache node and route tree refactoring touches exactly the machinery that decides what HTML a crawler receives, and a regression there shows up as soft 404s or empty shells rather than as a build failure. Watch the cache and PPR entries if you run PPR, and wait for a stable tag.
SEO supply chain is clean for the window
No advisory published on September 25, 26, or 27 in the GitHub Advisory Database affects an SEO package, sitemap generator, or crawler dependency; the npm advisories in that window covered unrelated packages. Registry metadata also shows no new releases of next-sitemap, next-seo, @nuxtjs/sitemap, @astrojs/sitemap, web-vitals, or schema-dts in the window, the most recent being @nuxtjs/sitemap 8.5.1 on September 12 and web-vitals 6.2.2 on September 14. No action, recorded so the negative is on file.
Ship today
- Nothing in this window warrants an emergency pull request. The list below is small on purpose.
- Pin the six documented Search Analytics API type values explicitly in your reporting job, and add a comment that multimodal is UI-export-only as of September 27, 2026.
- Schedule a recurring manual export of the multimodal filter from Search Console so a baseline exists before the API catches up.
- Add creator, with a name and a profile URL, to your video JSON-LD template, and confirm any interactionStatistic you emit uses WatchAction, LikeAction, CommentAction, or ShareAction.
- Validate the changed video template in the Rich Results Test before deploying, then hold your Next.js version at the current stable tag.
Comments
Share your thoughts and join the conversation