Daily SEO Note — August 18, 2026: Google Shuts Off the Content API for Shopping

1. SEO for Content Writers

The one change that reaches an editorial calendar today is a shutdown, not a ranking shift. Google's Content API for Shopping stops serving on 18 August 2026. If your product titles, descriptions, and attributes reach Google Merchant Center through that API, they stop reaching it today, and no amount of on-page quality compensates for a listing that has gone stale. Everything else in the window is quieter: an open Search Console logging error that is hiding AI impressions, and a spec revision worth a line in your brief template.

Google Turns Off the Content API for Shopping Today

Google's own quickstart carries the notice verbatim: "Content API for Shopping will be sunset on August 18, 2026." The Merchant Center help centre says the same thing and frames it as a hard stop — Google committed to "provide access to the Content API until August 18, 2026", and the Merchant API is the named successor. Rollout status: the sunset date is today.

Who this affects: any site whose product data is pushed to Merchant Center programmatically. That is retail and marketplace verticals, and it is invisible from the editorial side because nothing about the on-site product page changes. The failure looks like listings quietly ageing out of free product listings and Shopping surfaces while the pages themselves stay perfectly healthy.

What to do differently in the next product brief: before you commission or refresh product copy, ask engineering which pipeline actually delivers it to Merchant Center and whether that pipeline was cut over. A rewritten product title that never leaves your CMS is a rewrite you cannot measure. What to stop doing: stop treating feed copy and page copy as two disconnected workstreams owned by two teams who never compare notes — today is the day that gap becomes a visibility loss.

Search Console Has Been Under-Reporting AI Impressions Since 13 August

Google added an entry to its Data anomalies in Search Console page describing a logging error that reduced impressions on the Generative AI performance report in Search beginning 13 August 2026. Google's wording is specific and worth repeating to anyone reading your dashboards: the issue "affects data logging only and is ongoing." Nothing changed about how your pages are treated in AI surfaces. Only the counting broke.

Who this affects: every property with access to the Generative AI performance report, across all content types. It does not touch the Web search type, which is the number you should be making decisions on this week.

What to do differently: annotate every AI-surface chart from 13 August onward before anyone else reads it, and take AI impressions out of the inputs to this cycle's prune-and-consolidate list. What to stop doing: stop reading a post-13-August dip in AI impressions as lost visibility, and stop writing it into performance summaries. Because Google logs anomaly ranges rather than backfilling them, that dip will stay in your history permanently — the annotation is the only thing that will explain it in six months.

Ranking and Spam Surfaces Logged Nothing; the Volatility Chatter Stays Unconfirmed

One line, because that is all the evidence supports: the Search Status Dashboard shows no ranking, indexing, crawling, or serving incident inside the window, the last confirmed ranking event is still the June 2026 spam update that ran 24–26 June, and the Search documentation changelog has not added an entry since 29 July. Community reports of August volatility remain unconfirmed and should not be the reason a brief gets rewritten.

llms.txt v2 Makes the File an Editorial Asset, Not a Config File

The llms.txt proposal has been revised to v2. Its Changes page dates the revision to August 2026, and the spec page itself was last modified on 10 August 2026 — a week before it surfaced in the trade press, which is why it is here rather than in yesterday's note. Rollout status: it is a published community proposal, not a search engine requirement, so treat it as a watch item.

The writer-facing part is the shape of the file. It is an H1 with the site name, a blockquote summary, and H2 sections containing lists of markdown hyperlinks, each optionally followed by a colon and a short note. That note is the whole editorial job: it is the one line an agent reads before deciding whether to fetch the page. v2 also removed the mechanical meaning of the "Optional" section — it is still allowed as a convention for secondary links, but it no longer instructs any tool to skip anything.

What to do differently: add one field to your brief template — which llms.txt section this page belongs in, and its one-sentence description — and fill it when the page ships, not in a quarterly cleanup. What to stop doing: stop treating llms.txt as a sitemap and listing every URL. The proposal is explicit that the file stays small enough to fit in a context window and that the detail lives behind the links.

Unconfirmed: AI-Generated Images Appeared Inside AI Overviews, Then the Test Was Pulled

Labelled unconfirmed and deliberately excluded from the checklist below. Search Engine Roundtable reported on 17 August 2026 that AI-generated images were spotted inside AI Overviews and that the test was subsequently paused. There is no corresponding entry in Google's AI features documentation, which still carries a last-updated date of 10 December 2025. Note it if you are budgeting custom illustration for explainer content; do not plan against it.

Apply to Your Next Brief

• Before commissioning product copy, confirm with engineering that the Merchant Center pipeline was cut over — the Content API stops responding today.
• Annotate every AI-surface performance chart from 13 August and exclude that range from rewrite, prune, and consolidation decisions.
• Make the Web search type the deciding number this week; leave the Generative AI report out of the narrative until Google marks the anomaly resolved.
• Add two fields to the brief template: the llms.txt section the page belongs in, and its one-sentence description.
• Do not commission recovery content against August volatility. Nothing is logged on the Search Status Dashboard, so there is no confirmed change to recover from.
• Keep feed copy and page copy in the same review. Titles and descriptions that diverge between the two are now a single team's problem.

2. SEO for Developers

One breaking change, and it lands today. The Content API for Shopping reaches its sunset date on 18 August 2026 and there is no transition period behind it. Everything else in the window is small: a WordPress RCE whose CVE record went public yesterday against a patch that shipped six days ago, an additive discoverability convention in llms.txt v2 you can ship as a response header, and an open Google-side logging error your monitors should be told about.

Content API for Shopping Reaches Its Sunset Date Today

Identifier and date: Content API for Shopping, sunset 18 August 2026, per the notice on Google's Get started guide and the Merchant Center help centre. Breaking. Symptom if ignored: product upload, inventory, and price jobs stop receiving responses; Merchant Center data goes stale and listings fall out of free product listings and Shopping surfaces with no signal on the site itself.

What to change: the host and request line in your feed client. The Merchant API products guide gives the replacement verbatim — POST to merchantapi.googleapis.com/products/v1/accounts/{ACCOUNT_ID}/productInputs:insert with dataSource=accounts/{ACCOUNT_ID}/dataSources/{DATASOURCE_ID} as a query parameter. Grep first; a repository that has already migrated its main path often still has a cron job or a one-off backfill script pointed at the old host.

#!/usr/bin/env bash
# Content API for Shopping stops responding on 2026-08-18.
# 1) find every caller, 2) prove the replacement works.
set -euo pipefail

grep -rIn --exclude-dir=node_modules --exclude-dir=.git \
  -e 'shoppingcontent.googleapis.com' \
  -e 'content/v2\.1' \
  . || echo "clean: no Content API for Shopping callers left"

# Merchant API v1 request line, from the products guide.
curl -sS -o /dev/null -w 'merchant-api: HTTP %{http_code}\n' -X POST \
  "https://merchantapi.googleapis.com/products/v1/accounts/${ACCOUNT_ID}/productInputs:insert?dataSource=accounts/${ACCOUNT_ID}/dataSources/${DATASOURCE_ID}" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  --data @product-input.json

CVE-2026-65640 Went Public Yesterday Against a Patch That Shipped on 12 August

Identifier and date: CVE-2026-65640, published 2026-08-17 at 20:55 UTC, CVSS 3.0 base score 8.8, CWE-434. It is an authenticated Author-or-above remote code execution: a user with the upload_files capability uploads a crafted PostScript file, ImageMagick hands it to Ghostscript, and the server runs it. The patch is older than the record — WordPress 7.0.4 shipped on 12 August 2026 and the fix was backported to every branch back to 4.7. Rollout status: patch available, CVE record now public, no confirmed exploitation.

Non-breaking to fix, and the exposure is conditional: only servers running both Imagick and Ghostscript are exploitable. Cloudflare's WAF changelog for 2026-08-17 refined two WordPress RCE rules to name this CVE, with detection behaviour and actions unchanged — so managed-rule coverage is not new protection, just newly labelled. Symptom if ignored: an Author-level account, including any compromised contributor login, becomes a shell on the box that serves your pages, which is a search problem the moment injected content or redirects land in the index.

#!/usr/bin/env bash
# CVE-2026-65640: Author+ RCE via PostScript upload when Imagick and Ghostscript coexist.
set -euo pipefail

wp core version   # 7.0.4, or the backported release on your branch

php -r 'echo "imagick: ", extension_loaded("imagick") ? "yes" : "no", "\n";'
command -v gs >/dev/null && echo "ghostscript: yes" || echo "ghostscript: no"

# Defence in depth: refuse the coders the exploit rides on.
convert -list policy | grep -iE '(^|[^A-Za-z])(PS|EPS|PDF|XPS)' \
  || echo "no coder policy set for PS/EPS/PDF - add one in policy.xml"

wp core update && wp core update-db

llms.txt v2 Adds Link Relations You Can Ship Without Touching a Template

Identifier and date: llms.txt v2, dated August 2026 on its Changes page, with the spec page returning a Last-Modified of 10 August 2026. Non-breaking and purely additive. Symptom if ignored: nothing breaks; agents simply keep guessing at whether a markdown twin of a page exists.

What to change: emit two link relations. rel="alternate" type="text/markdown" points at a page's markdown version, and rel="describedby" points at the llms.txt file that covers it. v2 allows both URL forms for the markdown twin — page.html.md and page.md — and defines subpath scoping, so /docs/llms.txt covers everything under /docs/ and the most specific file wins. Because the relations are valid as an HTTP Link header, this is a CDN or web-server config change rather than a template change, and it works for non-HTML resources too.

# llms.txt v2 discoverability, emitted at the edge. No page templates touched.
location ~ ^/docs/(?<page>.+)\.html$ {
    add_header Link '</docs/$page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"' always;
}

location = /docs/llms.txt {
    default_type text/markdown;
    add_header Cache-Control "public, max-age=3600" always;
}

Tell Your Monitors About the Search Console AI Logging Error

Identifier and date: Search Console data anomaly, Generative AI performance report in Search, starting 13 August 2026, logged by Google on the Data anomalies page as affecting "data logging only" and still open. Non-breaking, but noisy. Symptom if ignored: an impressions-drop alert pages the on-call for a Google-side counting bug, and every downstream job that treats Search Console as ground truth — bulk data export tables, weekly rollups, anomaly detectors — inherits an understated range that will never be backfilled.

What to change: put the anomaly window in the monitor as data, not as a muted alert, so it self-documents and expires when Google closes the entry. Leave the end date open until the anomalies page says resolved.

from datetime import date

# Google logged a logging error reducing impressions on the Generative AI
# performance report in Search, starting 2026-08-13. Data logging only, ongoing.
# https://support.google.com/webmasters/answer/6211453
GENAI_ANOMALY_START = date(2026, 8, 13)
GENAI_ANOMALY_END = None  # set the day Google marks the anomaly resolved


def is_alertable(row: dict) -> bool:
    """Suppress AI-surface impression alerts inside Google's logged anomaly window."""
    if row["search_type"] != "generative_ai":
        return True
    if row["date"] < GENAI_ANOMALY_START:
        return True
    return GENAI_ANOMALY_END is not None and row["date"] > GENAI_ANOMALY_END

Next.js Shipped One Canary in the Window and None of It Is SEO-Facing

Identifier and date: 16.3.1-canary.22, published 2026-08-17 at 23:55 UTC per the npm registry metadata. The contents are Turbopack persistence tombstones, garbage-collection plumbing, a 32-bit usize conversion fix, and CI dispatch repairs. Non-breaking, and nothing to pick up: no change to the Metadata API, app/sitemap.ts, app/robots.ts, revalidation semantics, or image optimization. Stable remains 16.3.1. Rollout status: canary only. No action.

Ship Today

1. Grep for shoppingcontent.googleapis.com and content/v2.1 across every repo, cron job, and serverless function, then move any live caller to Merchant API v1. This is the only item on the list with a same-day deadline.
2. Run a post-cutover smoke test that inserts one product input and asserts a 200 from merchantapi.googleapis.com before the first scheduled feed run.
3. Update WordPress to 7.0.4, or the backported release on your branch, anywhere Imagick and Ghostscript are both installed, and add a policy.xml entry refusing the PS, EPS, PDF, and XPS coders.
4. Add 2026-08-13 as the start of an open anomaly window in whatever alerts on Generative AI impressions, so the Google-side logging error stops paging your on-call.
5. If you already publish markdown twins of your docs, add the rel="alternate" and rel="describedby" Link headers at the CDN. Header-only change, no deploy of page templates required.