Daily SEO Note — September 1, 2026: Google Splits Site Reputation Enforcement Along EEA Lines

Audit window: 31 August 2026 06:00 UTC to 1 September 2026 06:00 UTC. Two items took effect inside that window but were announced on 28 August, and are dated accordingly below. Every claim traces to a primary source with a publication date and a rollout status; industry coverage was used only to find candidates, never as the citation of record.

SEO for Content Writers

The consequential editorial change today is jurisdictional. Since 30 August 2026, a manual action under Google's site reputation policy no longer produces one global outcome: it demotes the affected section for searchers outside the European Economic Area, while inside the EEA the demotion does not apply at all. If you commission third-party, partner, or sponsored content, the risk attached to that content now depends on where your readers are.

Site reputation manual actions now split along EEA lines

Google adjusted how it enforces the site reputation policy after discussion with the European Commission, and the new behaviour began on 30 August 2026. Outside the EEA a manual action still directly affects search results for the portion of the site involved, and the rest of the site is untouched. Inside the EEA the impact of the manual action does not apply; instead the affected section may be separated in Google's systems so that, over time, it ranks independently from the rest of the site. The announcement was posted by the Google Search Quality team on Friday, 28 August 2026, and the policy documentation was updated the same day.

This affects one content type rather than a whole site: third-party material published on a domain that did not produce it — hosted partner sections, sponsored subfolders, coupon and deals verticals, syndicated columns. It does not touch your own editorial output.

Concretely, in your next brief for any hosted third-party section, state the primary audience market on the brief itself. A section aimed at EEA readers carries a materially different downside than one aimed at the US, and that changes whether the section is worth commissioning at all. Also note that a page can carry a manual action whose effect is only ever visible to searchers outside the EEA, so a colleague in Berlin and a colleague in Chicago can legitimately see different results for the same URL.

Stop reporting a manual action as a single global traffic event. If one lands, segment the drop by market before you write the post-mortem, or you will misattribute an EEA-flat, US-down pattern to something else entirely. Site owners are still notified in Search Console and can still file a reconsideration request; eligible sites may additionally bring disputes to mediation.

Google now spells out the four criteria it weighs on third-party content

Alongside the enforcement change, the spam policies documentation was updated on 28 August 2026 to list the criteria Google considers. It asks whether the graphic design, formatting, typography and UX of the content are consistent with the host domain; whether quality issues appear on the page that do not appear on the main domain; whether there is an explicit acknowledgement of ownership or responsibility for the content; and whether the content appears on multiple other sites in identical or near-identical form. Google states that not one of these factors is either necessary or sufficient on its own.

This is the most directly actionable item of the day because it converts a vague policy into four things an editor can check before publication. Turn each into a line on the brief: template parity with the main site, quality parity with the main site, a named and visible owner, and originality checked against other domains.

Stop shipping partner content in a stripped-down template that visibly differs from your main article layout, and stop burying attribution in a footer disclaimer — the criterion asks for explicit acknowledgement of ownership, which belongs in the byline area where a reader meets it. Stop running syndicated copy verbatim; if a piece already exists elsewhere in near-identical form, rewrite it or decline it.

A production crawler now enforces the Content Signals use directive

On 31 August 2026 Cloudflare shipped a change so that its Browser Run crawl endpoint respects the Content Signals use directive. The practical meaning for editorial teams is that a file most writers never see — robots.txt — now decides whether an automated system may reproduce your article in full or may only reference it, and at least one production crawler enforces that decision by refusing the request outright.

This affects all content, but it matters most wherever you are competing for citations in AI answers rather than for classic blue links. The eligibility question sits upstream of anything you can fix in the copy: no phrasing, structure, or schema makes you quotable if the site-level signal says no.

The editorial instruction is to make that call deliberately and per content type, then hand it to engineering as a requirement rather than leaving it to a default. A reference publication that wants to be cited in AI answers but not used for model training wants a different setting than a paywalled investigation. The configuration itself is in Section 2; the decision is yours, not engineering's.

Google listed the favicon formats it actually supports

The favicon documentation was updated on 28 August 2026 to name the supported formats explicitly: BMP, GIF, ICO, PNG, JPEG, PPM and TIFF. The file must be square and at least 8x8 pixels, with larger than 48x48 recommended. Google is explicit that its supported formats have not changed and that the documentation previously linked to an external reference which drifted over time.

This is documentation, not a behaviour change, and it affects the small brand mark shown beside your title link. There is no action unless your site serves an SVG favicon, which is not on the list. Do not schedule a favicon project off the back of this.

The European search data licensing program page was refreshed

The Google European Search Dataset Licensing Program page was updated on 31 August 2026 with a refreshed program overview, eligibility criteria and application details — the only primary Google documentation change dated inside today's window, per the documentation changelog.

It is informational for publishers. The program licenses anonymised search data to qualifying online search engines directed at EEA users under the Digital Markets Act, and the eligibility criteria explicitly exclude applicants that operate SEO businesses. Noted here because it sits on the same DMA thread as the site reputation change above, not because it asks anything of you.

Unconfirmed: AI Overviews expanding by default on some queries

Community reports collected in the Search Engine Roundtable recap for 31 August 2026 describe Google testing a fully expanded AI Overview on some queries, loading the follow-up prompt box by default and pushing organic results further down. This is unconfirmed. Google has published nothing on it, and the Search Status Dashboard logged no ranking or serving incident during the window.

Treat it as a watch item only. It is deliberately excluded from the checklist below, and it is not a basis for changing layout, above-the-fold strategy, or forecasts until Google confirms it or the pattern holds in your own Search Console data.

Apply to your next brief

• Add a market line to every brief covering partner, sponsored, or syndicated content, naming whether the audience sits inside or outside the EEA.
• Turn Google's four site reputation criteria into brief checkboxes: template parity, quality parity, a named owner, and originality checked against other domains.
• Move ownership statements on third-party articles out of footer disclaimers and into the byline area.
• Retire verbatim syndication — rewrite near-identical pieces or decline them.
• Decide, per content type, whether you want to be quotable in AI answers and whether you permit training use, then pass that to engineering as a robots.txt requirement.
• Segment by market before writing any manual-action post-mortem from 30 August onward.
• Leave the favicon and your above-the-fold layout alone this cycle; neither has a confirmed behaviour change behind it.

SEO for Developers

Next.js restored AVIF image optimization on 31 August 2026 at 20:02 UTC, closing a six-day gap in which patched applications served AVIF files entirely unoptimized. If you took the 25 August security release and have AVIF anywhere in your image pipeline, you have been shipping origin-resolution files to every visitor since, silently, with no error and no build warning. That is today's most consequential engineering change and it is measurable in your LCP.

Next.js 16.3.4 and 15.5.25 re-enable AVIF image optimization

Next.js v16.3.4 (Active LTS) and v15.5.25 (Maintenance LTS) both shipped on 31 August 2026 at 20:02 UTC, re-enabling AVIF image optimization when a newer sharp is installed. The upgrade itself is non-breaking. Staying put is the problem: on 16.3.3 or 15.5.24 the Image Optimization API does not resize or re-encode AVIF input at all — those files are served as-is.

The symptom if you ignore it is a quiet Core Web Vitals regression rather than a failure. AVIF routes serve originals at full resolution, transfer size climbs, LCP degrades on image-led templates, and nothing in the build output tells you. Change the Next.js version in package.json, then confirm what sharp actually resolved to in your lockfile.

# Active LTS (16.x)
npm install [email protected]

# Maintenance LTS (15.5.x)
npm install [email protected]

# AVIF optimization only comes back if sharp satisfies ^0.34.3 || ^0.35.4
npm ls sharp

The actual gate is the libheif version bundled inside sharp

The 25 August patch existed because of GHSA-g89c-p67h-r497, a heap buffer overflow in libheif rated 9.8 critical, in which a crafted AVIF file with nested identity-derivation and auxiliary item references makes scale_nearest_neighbor() write 16-bit samples into an 8-bit alpha plane. Through sharp, that reached Next.js as GHSA-2xp9-vwfh-vxw4, unauthenticated remote code execution rated 9.5, affecting Next.js from 10.0.0 up to 15.5.24 and every 16.x through 16.3.2. libheif is fixed in 1.23.2; anything at or below 1.23.1 is vulnerable.

This is why upgrading Next.js alone may not restore AVIF. Rather than switching optimization back on unconditionally, the fix adds a runtime libheif version guard in packages/next/src/server/image-optimizer.ts and raises the sharp requirement to ^0.34.3 || ^0.35.4. If your lockfile pins an older sharp — or your platform image ships an older libheif — the guard stays active and AVIF remains unoptimized after the upgrade. Verify the resolved versions rather than assuming.

# Print the libheif build actually linked into your installed sharp
node -e "console.log(require('sharp').versions)"

# Expect heif/libheif >= 1.23.2. At <= 1.23.1 the Next.js runtime guard
# stays on and AVIF input is passed through unoptimized.

# Also check the August 25 Windows-only RCE (CVE-2026-75604) is behind you.

The companion August 2026 security release notes cover the second critical issue from the same release: unauthenticated RCE on Windows-hosted servers using both the Pages Router and App Router without Cache Components. Linux and macOS are unaffected, and there is no workaround for affected Windows hosts.

Publish Content Signals in robots.txt — a production crawler now enforces them

As of 31 August 2026 Cloudflare's Browser Run crawl endpoint reads the Content-Signal directive from a target site's robots.txt and refuses work it is not permitted to do. That makes robots.txt an enforcement surface for AI usage preferences, not just a request for good behaviour. The directive takes the three signals search, ai-input and ai-train, each set to yes or no, under a User-agent record; omitting a signal expresses no preference either way.

This is non-breaking for your site and takes effect the moment the file is deployed. Put it in your robots.txt source of truth — a static public/robots.txt, or the generator if you use app/robots.ts — and make the values match the per-content-type decision from Section 1 rather than a default.

User-agent: *
Allow: /

# Content Signals: citable in AI answers, not usable for model training.
# search    = building a search index
# ai-input  = answer-time use (RAG, grounding)
# ai-train  = training or fine-tuning
Content-Signal: search=yes, ai-input=yes, ai-train=no

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

One caveat worth stating plainly: the three yes/no signals above are the verified Cloudflare syntax. The separate use level that the changelog references — the reference and full values discussed in the next item — comes from the IETF AI preferences work, and its exact robots.txt spelling was not verifiable from a primary source at the time of writing. Ship the three signals now; do not guess at the fourth.

Set crawlPurposes and contentUse if you call the crawl endpoint yourself

The same change cuts the other way if your team uses Cloudflare's crawl endpoint for RAG ingestion or content monitoring. Per the crawl endpoint parameter documentation, crawlPurposes defaults to all three values — search, ai-input and ai-train — and contentUse defaults to full, the most permissive level. Those defaults are now actively hostile to restrictive targets.

The symptom is a hard failure, not a silent skip: if a target's robots.txt sets any declared purpose to no, or sets a use level more restrictive than your declared contentUse, the request is rejected at initiation with 400 Bad Request and the message "Crawl disallowed by Content-Signal directive (purpose or use level)". Narrow your declaration to what you actually need, and handle the 400 as an expected outcome in your ingestion pipeline rather than an incident.

curl -X POST \
  'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com",
    "crawlPurposes": ["search"],
    "contentUse": "reference",
    "formats": ["markdown"]
  }'

# Defaults are crawlPurposes ["search","ai-input","ai-train"] and
# contentUse "full" -> a restrictive target returns 400 at initiation.

Supported favicon formats are now explicit in the documentation

Google's favicon documentation was updated on 28 August 2026 to list supported formats directly instead of linking to a drifting external reference: BMP, GIF, ICO, PNG, JPEG, PPM and TIFF. Square, minimum 8x8, larger than 48x48 recommended. This is non-breaking and changes no behaviour — Google states the supported formats themselves have not changed.

The only real symptom is for sites serving an SVG favicon, which is absent from the list. If that is you, emit a raster fallback from your head markup and keep the URL stable, since a stable favicon URL is what Google's guidance asks for.

<!-- Raster favicon for Google Search; keep this URL stable -->
<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/icon-192.png" type="image/png" sizes="192x192">

<!-- SVG may stay for browsers, but it is not a Google-supported format -->
<link rel="icon" href="/icon.svg" type="image/svg+xml">

Nothing else in the developer surface produced a verified change inside the window. Chrome, Lighthouse and the web-vitals library published no new release; Schema.org remains at v30.0 from 19 March 2026; the Search Status Dashboard reported no crawling, indexing, ranking or serving incident, with the August 2026 spam update long since complete (18–21 August, 2 days 16 hours); and the Bing Webmaster Blog has not posted since February 2026.

Ship today

1. Upgrade to [email protected] (16.x) or [email protected] (15.5.x).
2. Verify sharp resolves to ^0.34.3 || ^0.35.4 and that its bundled libheif is 1.23.2 or newer, or AVIF stays unoptimized despite the upgrade.
3. Re-measure LCP on AVIF-heavy templates and purge the image cache so unoptimized originals are not still served from the CDN.
4. Add a Content-Signal line to public/robots.txt carrying the per-content-type decision made by the editorial team.
5. If you call Cloudflare's /crawl endpoint, set crawlPurposes and contentUse explicitly and treat 400 as an expected response.
6. Windows-hosted Next.js only: confirm you are past CVE-2026-75604 from the 25 August release; there is no workaround.