Daily SEO Note — August 31, 2026: Google Carves the EEA Out of Site Reputation Enforcement

Lookback window for this edition: 72 hours, from 09:00 UTC on Friday, August 28 to 09:00 UTC on Monday, August 31, 2026 — extended over the weekend as the series does on Mondays. Every item below traces to a primary source with a date and a rollout status. Timestamps are UTC.

1. SEO for Content Writers

The single most consequential editorial change today is jurisdictional rather than algorithmic. As of Sunday, August 30, a site reputation manual action no longer suppresses the penalized section of a site for people searching inside the European Economic Area. Google published the change on Friday, August 28, and it took effect two days later. If you commission, host, or syndicate third-party content, your risk profile now differs by the searcher's location, not by the content itself.

Google stops applying site reputation manual actions inside the EEA

Google's Update to the Site Reputation Policy, posted by the Search Quality team on August 28, 2026, states that from August 30 a manual action issued under the site reputation policy has a different effect depending on where the search happens. Outside the EEA, the action behaves as it always has: it directly affects search results for the affected portion of the site, and the rest of the site is untouched. Inside the EEA, the post says plainly that "the impact of the manual action won't apply." Google attributes the change to discussion with the European Commission, and says in the same post that it remains concerned an overbroad application of the DMA could stop it from addressing real threats to result integrity.

Read the second half of that sentence carefully, because it is the part with editorial consequences. Google writes that the affected section "may be separated in our systems so that, over time, it ranks independently from the rest of the site." That is not an amnesty. It is the removal of the borrowed authority that made the tactic work in the first place. A coupon hub or sponsored-review section that has been ranking on the strength of the parent domain will, inside the EEA, be asked to rank on what it can earn alone.

This affects one content type rather than all content: third-party or partner material published on a host domain — coupon sections, sponsored review verticals, guest-post programmes, white-label hubs. It does not change anything for first-party editorial. Notification behaviour is unchanged: site owners are still told in Search Console when a manual action is applied, reconsideration requests still work, and Google adds that eligible sites can now bring disputes to mediation after a reconsideration request.

What to do differently in your next brief: if you run a hosted third-party section aimed at EEA readers, stop treating the parent domain's authority as the plan. Brief that section as if it were a standalone publication — its own topical depth, its own author credentials, its own first-hand testing. What to stop doing: stop signing syndication or partner deals whose traffic model is "it will rank because it sits on our domain." Outside the EEA that is still a policy violation under the spam policies; inside it, it is now simply an assumption that has stopped paying.

AI Overviews are expanding into AI Mode by themselves on some queries

Google is showing an expanded, AI Mode-style response directly in the AI Overview for some queries, without the searcher clicking the "Show more" control that previously gated it. A Google spokesperson confirmed the behaviour in a statement reported on August 28, 2026: "For some queries, AI Overviews may dynamically expand for topics where our systems determine it's most useful for people." Google added that if a user has already started scrolling past the AI Overview, the expansion is cancelled so the reader does not lose their place.

Rollout status matters here and it is limited: this is a confirmed behaviour on some queries, not a documented feature. Nothing about it appears in Google's AI features documentation, which was last updated on December 10, 2025 and still says there are no additional requirements or special optimizations needed to appear in AI Overviews or AI Mode. Treat the expansion as a live experiment whose surface area may change without notice.

Who it affects: any vertical where AI Overviews already trigger, with the sharpest effect on informational and comparison queries — exactly the ones where an expanded answer occupies the space a reader would have scrolled through. What to do differently: front-load the passage that answers the query. The material that gets quoted into an expanded response is a clean definition, a comparison table, or a directly stated answer, not a narrative wind-up. What to stop doing: stop writing the 150-word contextual preamble before the answer. It was already weak practice; on a query that dynamically expands, it is invisible.

Google now names the favicon formats it accepts, instead of pointing elsewhere

Google's documentation changelog records an August 28, 2026 update to the favicon guidance. The reason given is precision: the documentation previously referenced external sources for supported formats, and those sources "evolved over time and caused ambiguity." The favicon documentation, now stamped last-updated 2026-08-28, lists the accepted formats outright — BMP, GIF, ICO, PNG, JPEG, PPM and TIFF — and restates the shape requirement: a square, at least 8x8 pixels, with larger than 48x48 recommended.

This is a clarification, not a policy change, and no favicon that was eligible last week has become ineligible. It is on the writer track because the favicon is a brand asset that appears beside your headline in the result, and in most publishing teams nobody owns it. Who it affects: all content, but only once — this is a check, not a recurring task.

What to do differently: add a one-line favicon check to your site-launch and rebrand checklists, and cite the Google page rather than a third-party listicle. What to stop doing: stop treating SVG as a safe answer for the search favicon. It is not on Google's list.

Your rank-tracking numbers are the least trustworthy thing on your desk this week

Google confirmed on August 26, 2026 that it is rewriting the links inside its search results so that each one points at an encoded google.com/goto redirect rather than at the destination URL. Google's statement framed it as a technical measure against evolving forms of abuse. The rank-tracking firm Nozzle reported near-total coverage on the same day, after roughly four months of intermittent testing.

The reporting does not show that this changed how Google ranks or indexes anything, or which page a searcher reaches after clicking. It changed how measurement tools read a results page: the destination is no longer written in the link, so a tracker must follow every redirect to recover it. Nozzle put the cost at 500 to 1,000 requests to resolve a five-page ranking. Expect your vendors to be slower, more expensive, or quietly less complete for the next few weeks — and expect that to look, in a dashboard, exactly like a ranking drop.

What to do differently: for the next fortnight, do not commission a rewrite, a consolidation, or a pruning decision on the strength of a position delta alone. Corroborate against Search Console impressions and clicks, which are unaffected because they never depended on parsing the SERP. What to stop doing: stop reporting week-over-week average position as a headline metric until your vendor confirms how it is resolving goto links.

No ranking system update is running

Nothing started or finished on the Search Status Dashboard during the window; it read "No incidents" across crawling, indexing, ranking and serving as of its last update on August 30, 2026. The most recent ranking event, per the dashboard's ranking history, is the August 2026 spam update, which began on August 18 and ran for 2 days and 16 hours. There is no core update, spam update or Discover update in flight, and no Quality Rater Guidelines revision or Search Essentials change landed in the window.

Apply to your next brief

• If the piece runs in a hosted third-party section and targets EEA readers, brief it to stand alone: independent topical depth, a named author with verifiable credentials, and at least one first-hand or proprietary element.
• Move the direct answer, definition, or comparison table above the fold of the article body. Cut the contextual preamble.
• Freeze rank-position-driven rewrite decisions for two weeks; validate any decay claim against Search Console impressions and clicks instead.
• Add "favicon present, square, PNG or ICO, larger than 48x48" to the launch and rebrand checklists.
• Stop pitching syndication and guest-post placements on the argument that the host domain's authority will carry them.
• Leave the dynamic AI Overview expansion out of forecasts. It is confirmed behaviour on some queries, but it is undocumented and may change.

2. SEO for Developers

The engineering change that costs you something today is google.com/goto. It is not a ranking or indexing change, so nothing in your rendering or crawl path needs to move — but it breaks the assumption that a result link contains a destination URL, and that assumption is wired into rank-tracking contracts, referrer parsing, and any internal script that reads a SERP. Everything else in the window is small: one documentation clarification, one policy change with an architectural implication, and a crawler-policy check worth running because the inputs moved.

google.com/goto: audit referrer handling and reprice your rank-tracking contract

Rollout identifier and date: confirmed by Google on August 26, 2026, reported at near-total coverage the same day. Non-breaking for your site — no crawler behaviour, status code, or canonical resolution changes — but breaking for anything that parses result links. The symptom if ignored is not an error; it is a dashboard that shows a plausible-looking ranking decline caused entirely by a tracker that could not resolve redirects at full coverage.

There is no setting on your side to change, which is exactly why this needs an explicit verification step rather than a fix. Two things are worth confirming on your own traffic before you accept anyone's reporting: that organic sessions are still attributed to Google in your analytics, and that the referrer your server actually receives has not shifted. Do not take a vendor's word for either — measure the distribution in your own access logs.

#!/usr/bin/env bash
# Compare the referrer distribution for Google-referred hits before and after
# 2026-08-26, when google.com/goto reached near-total coverage.
# Run against your own access logs; do not infer the answer from vendor claims.

LOG="${1:-/var/log/nginx/access.log}"

awk '$0 ~ /google\./ {
    match($0, /"https?:\/\/[^"\/]*google\.[^"\/]*(\/[^"]*)?"/)
    if (RSTART) print substr($0, RSTART, RLENGTH)
}' "$LOG" \
  | sed 's/?.*$/?<stripped>/' \
  | sort | uniq -c | sort -rn | head -25

# Expect google.com/ and country TLDs to dominate. Investigate any new
# high-volume referrer value, and any collapse in total Google-referred hits
# that your Search Console click totals do not corroborate.

Search Console impressions and clicks are the control in this experiment: they are generated inside Google, never by parsing a results page, so they are unaffected by the redirect. Any decline that appears in a third-party tracker but not in Search Console is a measurement artifact until proven otherwise.

Favicon: Google now publishes the format list, and SVG is not on it

Version and date: documentation update logged August 28, 2026 in the Search documentation changelog; the favicon page carries a last-updated stamp of 2026-08-28. Non-breaking — this is a clarification, and Google's stated reason is that the page used to defer to external format lists that "evolved over time and caused ambiguity." The symptom if ignored is a site that ships only an SVG icon and gets no favicon rendered beside its results.

Supported formats are now stated outright: BMP, GIF, ICO, PNG, JPEG, PPM and TIFF. The file must be square and at least 8x8 pixels, with larger than 48x48 recommended. The setting to change is the icon link element in your document head — for App Router projects, the file-convention icon in the app directory or the icons key returned from your metadata export.

import type { Metadata } from 'next'

// Google's favicon documentation (updated 2026-08-28) lists BMP, GIF, ICO,
// PNG, JPEG, PPM and TIFF. SVG is not on that list, so ship a raster file
// for Search and keep the SVG only as a progressive enhancement for browsers.
export const metadata: Metadata = {
  icons: {
    icon: [
      { url: '/favicon.ico', sizes: '48x48', type: 'image/x-icon' },
      { url: '/icon-192.png', sizes: '192x192', type: 'image/png' },
    ],
    apple: '/apple-touch-icon.png',
  },
}

Serve the file from a stable URL and let Googlebot fetch it — the icon is discovered on crawl, so a robots.txt rule that blocks your image directory will suppress it. Confirm the element renders in the delivered HTML rather than only in a client-side head mutation; see the generateMetadata reference for how the icons key is emitted.

Site reputation, EEA edition: make the hosted section independently addressable

Rollout identifier and date: policy update published August 28, 2026, effective August 30, 2026. Non-breaking as shipped, but it changes what a good architecture looks like if you host third-party content. Google states that for EEA searchers the manual action's impact will not apply, and that the affected section "may be separated in our systems so that, over time, it ranks independently from the rest of the site."

Google's systems can only separate a section they can cleanly delineate. If partner content is interleaved with first-party editorial under shared path prefixes, you are relying on Google to infer a boundary you never drew. The setting to change is your routing and sitemap segmentation: give hosted content its own path prefix and its own sitemap file, referenced from a sitemap index, so the boundary is explicit and so you can measure the two halves separately in Search Console.

import type { MetadataRoute } from 'next'

// Keep first-party editorial and hosted third-party content in separate
// sitemaps under separate path prefixes. Google's site reputation update
// (2026-08-28) says an affected section may be separated so that it ranks
// independently — an explicit boundary is easier to separate than an
// inferred one, and it lets you filter the two apart in Search Console.
export default function sitemap(): MetadataRoute.Sitemap {
  return [
    {
      url: 'https://example.com/articles/',
      lastModified: new Date(),
      changeFrequency: 'daily',
      priority: 1,
    },
    {
      // Everything third-party lives under one prefix and nowhere else.
      url: 'https://example.com/partners/',
      lastModified: new Date(),
      changeFrequency: 'weekly',
      priority: 0.5,
    },
  ]
}

Manual actions are not exposed by the Search Console API, so this cannot be monitored programmatically — the manual actions report remains a human check. Put it on a named owner's recurring calendar rather than assuming a monitor will catch it.

OpenAI now documents four user agents, and the AdsBot IP file is live

Status as verified on August 31, 2026: OpenAI's crawler documentation lists four distinct agents — GPTBot for model training, OAI-SearchBot for ChatGPT search results, OAI-AdsBot for validating pages submitted as ChatGPT ad landing pages, and ChatGPT-User for user-initiated fetches. The published IP range file for AdsBot at openai.com/adsbot.json now returns HTTP 200 with a creationTime of 2026-05-12; industry reporting in April 2026 noted its absence, so reverse-verification for this agent is newer than the documentation entry itself. This is a status check rather than a change inside the 72-hour window, and it is included because the inputs to the decision have moved.

These are four separate decisions and should be four separate blocks in robots.txt, not one. Blocking GPTBot opts you out of training data; blocking OAI-SearchBot removes you from ChatGPT search answers, which is a traffic decision, not a rights decision. OpenAI's documentation notes that ChatGPT-User handles user-initiated actions and is not used to crawl the web automatically, so robots.txt rules may not apply to it in the way you expect. The file to change is public/robots.txt, and per RFC 9309 each user-agent group is matched by the most specific token, so name the agents exactly.

# Four OpenAI agents, four independent decisions.
# Source: https://developers.openai.com/api/docs/bots (verified 2026-08-31)

# Search: allow, so the site can be cited in ChatGPT search answers.
User-agent: OAI-SearchBot
Allow: /

# Training: opt out of generative model training.
User-agent: GPTBot
Disallow: /

# Ads: only fetches URLs submitted as ChatGPT ad landing pages.
# Allow if you run ChatGPT ads; verify by IP against openai.com/adsbot.json.
User-agent: OAI-AdsBot
Allow: /

# User-triggered fetches. Documented as not an automatic crawler.
User-agent: ChatGPT-User
Allow: /

# Google's AI training opt-out is separate from Googlebot and does not
# affect Search indexing or AI Overviews eligibility.
User-agent: Google-Extended
Disallow: /

Sitemap: https://example.com/sitemap.xml

Verify enforcement rather than intent. Fetch your own robots.txt through the CDN, not from origin, and confirm no bot rule or WAF managed ruleset is answering these agents differently from what the file says. Google's common crawlers reference is the equivalent list on the Google side and is worth diffing against your file at the same time.

No advisories affecting SEO packages in the window

The reviewed npm advisories published on August 28, 2026 in the GitHub Advisory Database covered the mariadb connector and the 9router proxy. Neither is an SEO package, CMS plugin, or crawler dependency. No advisory landed in the window for next-sitemap, next-seo, the Nuxt or Astro sitemap modules, or any structured-data tooling. Schema.org remains at version 30.0, released 2026-03-19, with no release in the window.

Ship today

1. Run the referrer distribution check against your own access logs and compare the Google-referred total to Search Console clicks for the same dates. Do this before accepting any ranking report dated after August 26.
2. Confirm a raster favicon (ICO or PNG, square, larger than 48x48) is referenced in the delivered HTML and is not blocked by robots.txt. If the site ships only an SVG icon, add a raster file.
3. Split public/robots.txt into four named OpenAI user-agent groups plus Google-Extended, then fetch the file through the CDN to confirm the edge is not overriding it.
4. If you host third-party or partner content, move it behind a single path prefix and give it its own sitemap entry, so the section is explicitly delineated rather than inferred.
5. Assign a named owner to check the Search Console manual actions report on a recurring schedule. There is no API for it.

Method and evidence

Window: 2026-08-28 09:00 UTC to 2026-08-31 09:00 UTC. Sources checked and found unchanged in the window: Search Status Dashboard, Google ranking update history, Search Central Blog, Schema.org releases, the Bing Webmaster Blog, and the Vercel and Cloudflare changelogs. Two items above — google.com/goto and the OpenAI crawler roster — are dated just outside the window and are labelled as such; they are included because their rollout status is still moving. The dynamic AI Overview expansion is confirmed by a Google statement to the press but has no corresponding entry in Google's documentation, and is treated accordingly.