Daily SEO Note — September 12, 2026: Google's EEA Aggregator Units Take the Top Slot

1. SEO for Content Writers

The most consequential editorial change today is not an algorithm update. Google's Search Status Dashboard reported no crawling, indexing, ranking or serving incidents through September 11, and the documentation changelog logged nothing new between September 9 and 12. What is reshaping results instead is a layout change: Google's regional search features documentation, published September 8 and now live across the European Economic Area, gives the most valuable slot in travel and local results to aggregators rather than to the businesses being aggregated.

Aggregator and supplier units hand the top EEA slot to comparison sites

Google's new regional differences in Search experience page documents an aggregator unit and a supplier unit that appear in the European Economic Area for hotels, flights, transportation and products. The aggregator unit gives visibility to comparison and booking platforms; the supplier unit highlights the businesses that actually provide the service. Ecosystem carousels for weather, sports, finance and translation sit alongside them, and separate job and places features run in the EEA and Türkiye.

This affects one vertical group hard rather than all content evenly. If you publish for a hotel, airline, restaurant or transport brand targeting EEA users, the page that used to compete for the top organic result is now competing underneath a unit built for aggregators. Google's own framing is blunt about the trade-off, and the rollout is a compliance response to the Digital Markets Act rather than a quality improvement.

The editorial instruction is to stop writing EEA travel and local pages as if a direct-booking page can win the top slot on brand-plus-category queries. Write for the queries the units do not absorb: specific property or route detail, first-hand stay and journey reporting, policy and eligibility questions, and the long-tail comparisons that a three-result unit cannot cover. Stop building thin "book direct" landing pages whose only argument is price, because the carousel above them no longer shows live pricing or availability and your page is not what fills that gap.

Structured data carousels are the one regional unit you can opt into

Buried in the same document is the one feature on the list that is earned rather than assigned: the structured data carousel, a horizontally scrollable rich result drawing multiple entities from a single site. Unlike the aggregator and supplier units, which Google populates algorithmically, this one requires markup you control — and it is available in multiple regions, not only the EEA.

Google's carousel documentation limits eligibility to list pages where every item is the same type, currently course, movie, recipe and restaurant content, with a minimum of two items. That is a real editorial constraint, not a technical footnote. A roundup mixing a recipe, a restaurant and a gift guide is ineligible by construction.

What changes in practice: when you commission a list article for one of those verticals, commission it as a genuine summary page — a consistent entity type, a stable order, and a detail page on your own domain behind every entry. Sending carousel candidates to third-party URLs disqualifies them, since the linked detail pages must live on the same site.

Search Console's June indexing history is gone for good

Publishers noticed on September 11 that the page indexing report had lost its June 2026 history. John Mueller of Google responded on Bluesky that the gap traces back to June's reporting delay — there is simply no data for the period because the report never updated — and that Google does not back-fill indexing data. He added that he would confirm with the team after the holidays, so treat the explanation as reported rather than formally documented.

The practical consequence for editorial teams is narrow but real. If your content refresh or pruning programme uses indexed-page counts as its before-and-after measure, June is now a hole in that series and will stay one. Google's page indexing report documentation is explicit that the report is not a precise inventory in the first place: example URLs cap at 1,000 per status and totals are not meant to match your own count of site URLs.

Stop citing month-over-month indexed-page deltas across the June boundary in content performance reviews. Where a decayed-page consolidation shipped in Q2, re-baseline it against a period with continuous data and note the gap in the write-up rather than reporting a phantom drop.

Apply to your next brief

• For EEA travel, transport and restaurant briefs, drop the assumption of a top organic slot and target detail, policy and first-hand experience queries instead.
• Kill "book direct" outlines whose only differentiator is price — the unit above you no longer shows live pricing, and your page is not what replaces it.
• Commission list articles in course, movie, recipe or restaurant verticals as single-entity-type summary pages with at least two items, each linking to a detail page on your own domain.
• Re-baseline any content-pruning report that spans June 2026; the indexing series has a permanent gap and will not be back-filled.
• Do not present the EEA layout shift as a ranking penalty in stakeholder updates — it is a Digital Markets Act compliance change, and diagnosing it as a quality problem will send writers after the wrong fix.

2. SEO for Developers

The only shipped release inside today's window is Next.js 16.3.5, a non-breaking patch published September 11 at 19:15 UTC that fixes two real crawl-adjacent defects: a poisoned image disk cache and script tags served without a Content Security Policy nonce. Everything else worth engineering time today is markup and measurement work created by Google's September 8 regional features documentation.

Next.js 16.3.5 fixes image disk cache poisoning and missing CSP nonces

The v16.3.5 release notes list five backported fixes. Two matter for search. The first pair — "Skip 0-byte entries when initializing disk LRU cache" and "Reject empty images when reading/writing to the disk cache" — stops zero-byte files entering and being served from the next/image disk cache. If ignored, the symptom is broken or empty images served from cache long after the source is healthy, which degrades image search eligibility and Largest Contentful Paint on image-led templates.

The second is "Add CSP nonce to script tags of loading and template files". Without it, apps enforcing a nonce-based Content Security Policy have their loading and template scripts blocked by the browser. Rendering-dependent content behind those scripts fails for anything executing your JavaScript, Googlebot included. The release also fixes use cache prerender signal retention and emits whole-app server NFTs when output: 'standalone' is combined with an adapter — relevant if your deploy target prunes files by trace.

# Non-breaking patch upgrade from any 16.3.x
npm install [email protected]

# Verify the resolved version
npm ls next

# If you enforce a nonce-based CSP, confirm loading/template
# scripts now carry it:
curl -s https://example.com/ | grep -o '<script[^>]*nonce="[^"]*"' | head

Mark up summary pages with ItemList to stay eligible for regional carousels

Google's regional search features documentation makes structured data carousels the only listed regional unit a site can qualify for through its own markup. The carousel guidance requires an ItemList containing at least two ListItem entries, all of the same type, each with a 1-based position and a fully qualified url pointing at a detail page on the same domain.

This is non-breaking — nothing regresses if you skip it — but the eligibility is simply forfeited. Emit it from the summary-page template rather than hand-authoring per article, so ordering stays in sync with the rendered list. Validate with the Rich Results Test before shipping; a mixed-type list silently fails rather than erroring.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://example.com/recipes/tahini-cookies"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://example.com/recipes/zaatar-manakish"
    }
  ]
}
</script>

Own your indexing time series — Search Console will not rebuild it

The missing June 2026 page indexing history is, per Mueller's Bluesky reply on September 11, permanent: the report did not update during June's delay and Google does not back-fill indexing data. Treat this as the design, not an outage. The official report documentation already caps example URLs at 1,000 per status and disclaims exact totals.

The engineering fix is to stop treating the Search Console UI as your system of record. Schedule an export against the Search Console API into your own store, so a future reporting gap costs you nothing. Non-breaking, but the symptom if ignored is a permanent hole in whatever indexing series your team reports against.

#!/usr/bin/env bash
set -euo pipefail

SITE="https://example.com/"
OUT="data/gsc/$(date -u +%Y-%m-%d).json"
mkdir -p "$(dirname "$OUT")"

# Daily snapshot; run from cron so gaps in Google's UI never
# become gaps in your own history.
curl -sS -X POST \
  "https://searchconsole.googleapis.com/webmasters/v3/sites/$(python3 -c 'import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1],safe=""))' "$SITE")/searchAnalytics/query" \
  -H "Authorization: Bearer ${GSC_TOKEN:?set GSC_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
        "startDate": "'"$(date -u -d '3 days ago' +%F)"'",
        "endDate": "'"$(date -u -d '1 day ago' +%F)"'",
        "dimensions": ["page"],
        "rowLimit": 25000
      }' > "$OUT"

echo "wrote $OUT"

Audit robots.txt against OpenAI's current four-crawler roster

Not a change from today, but a live discrepancy worth a five-minute audit: OpenAI's crawler documentation now permanently redirects from platform.openai.com/docs/bots to developers.openai.com/api/docs/bots, and the documented roster is four agents, not the three most robots.txt files were written against. GPTBot (v1.4) crawls for model training, OAI-SearchBot (v1.4) surfaces sites in ChatGPT search, ChatGPT-User (v1.0) is user-triggered, and OAI-AdsBot (v1.0) — added to the docs on April 23, 2026 — validates pages submitted as ChatGPT ads.

Keep these decisions separate, because they are genuinely different trades: training access, search visibility, ad validation, and user-triggered fetches. Blocking OAI-SearchBot removes you from ChatGPT's search citations, which is rarely what a team means when it says it wants to block AI crawlers. OpenAI's documentation also notes that robots.txt rules may not apply to ChatGPT-User, since it acts on a user's behalf rather than crawling autonomously. Verify at the CDN too — a bot-management rule can override robots.txt intent in either direction.

# Search visibility in ChatGPT: allow.
User-agent: OAI-SearchBot
Allow: /

# Foundation-model training: opt out.
User-agent: GPTBot
Disallow: /

# User-triggered fetch on a person's behalf; OpenAI notes
# robots.txt may not apply. Stated intent, not enforcement.
User-agent: ChatGPT-User
Allow: /

# Ad landing-page validation. Only relevant if you run
# ChatGPT ads; blocking may fail your own ad review.
User-agent: OAI-AdsBot
Allow: /

Ship today

1. Upgrade to [email protected] and, if you enforce a nonce-based CSP, confirm loading and template script tags now carry the nonce.
2. Purge any next/image disk cache that may hold zero-byte entries, then redeploy on the patched version.
3. Add ItemList JSON-LD to summary-page templates in eligible verticals and validate with the Rich Results Test.
4. Schedule a Search Console API export into your own store so the next reporting gap does not erase your history.
5. Diff public/robots.txt against OpenAI's four documented crawlers and confirm your CDN bot rules agree with it.