Daily SEO Note — August 3, 2026: Google Stays Quiet, Next.js Patches a Soft-404 Path

1. SEO for Content Writers

There is no consequential editorial change to report today. This is a Monday edition, so the window was extended to 72 hours to cover the weekend, and across that full window Google published nothing to the Search Central blog, logged nothing on the Search Status Dashboard, and made no revision to the documentation changelog. Nothing below asks you to rewrite anything. The only writer-facing item worth your attention is a claim circulating in the trade press that no primary source supports.

Google's editorial surfaces produced nothing in the 72-hour window

Checked at 06:10 UTC on August 3, 2026: the Search Status Dashboard carries no ranking, crawling, indexing, or serving entry newer than the June 2026 spam update. The Search Central blog has published nothing since July 29, and the documentation changelog has no entry newer than July 29 either. Bing's Webmaster blog has been static since February.

The July 29 post confirming the global rollout of Search Console platform properties sits five days back, outside even the extended window, so it is not new business here. If you have not yet connected your Instagram, TikTok, X, or YouTube presence to Search Console, that remains the standing action item from last week rather than today's news.

This is the third consecutive edition in which Google's ranking and policy surfaces produced no verified change. Quiet stretches are not a signal to act on. Ranking-tracker volatility circulating without a corresponding dashboard entry stays unconfirmed and does not belong in a client report as an update.

Unconfirmed: the claim that the Search Console API drops FAQ data this month

Several SEO publications are stating that August 2026 is the month FAQ rich result data disappears from the Search Console API, and advising teams to patch dashboards and BigQuery exports before a deadline. Treat this as unconfirmed. It is flagged here so you recognise it, not so you act on it.

What Google itself documents is narrower. The feature stopped appearing in Search on May 7, 2026, and the documentation for it was removed on June 15, 2026. The Search Console API reference carries no deprecation notice for FAQ data and names no August date, and FAQ is simply absent from the structured data gallery. No primary source establishes an August cutoff.

The practical consequence is unchanged either way: FAQ has not been a SERP feature since May, so no article should be built around winning one. FAQPage markup remains valid Schema.org vocabulary and is harmless to leave in place, and other engines and retrieval crawlers still parse it. What you should not do is cite a specific August deadline to a client on the strength of trade coverage alone.

Apply to your next brief

• Change nothing on the basis of today's audit. No brief, title pattern, or outline needs revision from Google-side movement, because there was none.
• Strike any "FAQ rich result" goal still sitting in a template brief. That target has been dead since May 7, 2026, regardless of the API question.
• Do not put an August FAQ-API deadline in a client deliverable until Google documents one. Cite the May 7 and June 15 dates, which are documented, or say nothing.
• Use a quiet week for maintenance the news cycle usually crowds out: consolidate cannibalising pairs, refresh decayed evergreen pages, and fill entity gaps in existing hubs.

2. SEO for Developers

The most consequential engineering change in the window is a pair of Next.js canary fixes to how not-found routes render through deployment adapters — the exact failure class that turns a missing page into a soft 404. Nothing here is stable-channel yet, so this is a watch-and-verify day rather than an upgrade day, with one exception: a WPGraphQL advisory that started alerting on July 31 and has no patched release to upgrade to.

Next.js patches not-found rendering through adapters, twice in three days

Two consecutive Next.js canary releases touched the same subsystem. v16.3.0-canary.105 (July 31, 2026, 23:57 UTC) fixed adapter outputs for not-found routes when cache components are in use. v16.3.0-canary.106 (August 1, 2026, 23:56 UTC) fixed hybrid Pages/App Router not-found rendering with adapters. Both are non-breaking bug fixes on the 16.3 pre-release line; there is no stable release carrying them yet.

The symptom if you ignore it: on a deployment that mixes Pages Router and App Router and goes out through an adapter, a request for a genuinely missing URL can render the wrong not-found output. When that path returns HTTP 200 with not-found content rather than a real 404, Googlebot classifies it as a soft 404, the URL stays in the crawl rotation, and Search Console's Pages report fills with entries that look like an indexing problem but are a status-code problem.

This only bites the hybrid-router-plus-adapter configuration, so most single-router deployments are unaffected. The setting to change is none — there is no flag, only a version. The useful action today is verification rather than an upgrade: assert the status code your missing routes actually return, in the deployed environment rather than in dev, and keep that assertion in CI so a future adapter change cannot regress it silently.

#!/usr/bin/env bash
# Assert that missing routes return 404, not 200-with-not-found-content.
# Run against the deployed origin: dev mode can mask adapter behaviour.
set -euo pipefail

BASE="${1:?usage: check-404-status.sh https://example.com}"
PATHS=("/this-page-does-not-exist" "/blog/definitely-missing" "/en/missing")

fail=0
for p in "${PATHS[@]}"; do
  code=$(curl -s -o /dev/null -w '%{http_code}' "$BASE$p")
  printf '%-32s %s\n' "$p" "$code"
  [ "$code" = "404" ] || fail=1
done

exit "$fail"

Turbopack's build filesystem cache is now on by default

The same v16.3.0-canary.105 release (July 31, 2026) enabled turbopackFileSystemCacheForBuild by default, added an experimental.turbopackChunking option, and stabilised the deploy revalidation checks behind after(). Non-breaking, but the default flip is the part that matters operationally: build output now depends on cache state that persists between builds.

For SEO the risk is indirect but real. Anything generated at build time — sitemap routes, metadata resolved in generateMetadata, prerendered HTML — is only as fresh as the cache that produced it. A stale filesystem cache surviving across builds is a plausible cause of a sitemap or canonical set that does not match what you just deployed. Pin the flag explicitly rather than inheriting it, so a version rollback cannot quietly change your build output, and clear the cache in CI when you cut a release.

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    // canary.105 (2026-07-31) turns this on by default.
    // Pin it so a rollback to an older canary does not
    // silently change build output.
    turbopackFileSystemCacheForBuild: true,
  },
}

export default nextConfig

A WPGraphQL enumeration flaw starts alerting, with no patched release

GHSA-jhh7-832h-f8hv / CVE-2026-54768 affects the Composer package wp-graphql/wp-graphql at versions up to and including 2.6.0, rated Moderate at CVSS 6.9. The advisory was originally published June 9, 2026, but GitHub reviewed it on July 31, 2026 — and that status change is what lands it here, because review is the point at which it starts firing in Dependabot and dependency-graph alerts on every headless WordPress repository.

The mechanism is a deprecated user field on SendPasswordResetEmailPayload. The sendPasswordResetEmail mutation deliberately always returns success to prevent enumeration, but the deprecated field resolves to a full User object for a valid author-class username and null otherwise, exposing database IDs, names, descriptions, and URIs to an unauthenticated caller. It defeats the same hardening most teams already applied to the REST API.

There is no patched version listed, so upgrading is not the fix. Mitigate by removing the deprecated field from the exposed schema or blocking the mutation at the edge, and confirm the behaviour on your own endpoint first — if the user object comes back non-null for a real author and null for a fabricated one, you are exposed.

#!/usr/bin/env bash
# Probe CVE-2026-54768: does the deprecated `user` field leak
# whether an account exists? Run only against your own endpoint.
set -euo pipefail

ENDPOINT="${1:?usage: check-wpgraphql-enumeration.sh https://example.com/graphql}"

probe() {
  curl -s "$ENDPOINT" \
    -H 'Content-Type: application/json' \
    -d "{\"query\":\"mutation { sendPasswordResetEmail(input:{username:\\\"$1\\\"}) { user { databaseId name uri } } }\"}"
  echo
}

echo "--- likely-real account ---"
probe "admin"
echo "--- fabricated account ---"
probe "zzz-not-a-real-user-zzz"

# Non-null user for the first and null for the second = enumeration works.

Cloudflare opens Agents Week

Cloudflare opened Agents Week on August 2, 2026, a week-long announcement cycle covering compute, connectivity, security, and identity primitives for agent traffic. The kickoff post is informational and ships no setting you can change today, and the announcements so far — Cloudflare Mesh, a Wiz partnership — are not crawler-policy changes.

It is on the watch list for one reason: Cloudflare sits between your robots.txt intent and every AI crawler that honours it, so bot-management defaults announced this week are worth reading before they reach your zone. Track the developer changelog rather than the blog for anything that actually changes enforcement, and re-verify that your edge is not overriding robots.txt if a managed bot rule ships.

Ship today

1. Audit WPGraphQL. If wp-graphql is at 2.6.0 or below, probe your own endpoint, then strip the deprecated user field from SendPasswordResetEmailPayload or block the mutation at the edge. No patched release exists, so upgrading will not close it.
2. Add a 404 status assertion to CI against the deployed origin, not dev. This is worth doing today whether or not you run the 16.3 canary line.
3. If you track Next.js canaries, pin turbopackFileSystemCacheForBuild explicitly in next.config.ts and clear the build cache on release cuts.
4. Do not upgrade production to 16.3 pre-release for the not-found fixes. Verify your status codes instead and wait for the stable cut.