Daily SEO Note — September 18, 2026: AI Training Opt-Outs Split From Search Visibility

1. SEO for Content Writers
The most consequential editorial change today is a distribution change, not a ranking one. Google's Search profile documentation gained a badge guide on September 16, and the published eligibility bar sits at 10,000 followers on a single platform — putting a Google Discover distribution channel within reach of mid-size publishers who had written Discover off as a lottery. Google's ranking systems themselves were quiet: the Search Status Dashboard reported no incidents across crawling, indexing, ranking or serving, last updated 23:03 PDT on September 17. No core or spam update is in flight.
Google's Search profile badge turns followers into Discover reach
Google published a new guide on adding a Search profile badge to your website, logged in the documentation changelog on September 16, 2026; the guide itself carries a Last updated stamp of 2026-09-16 UTC. Status: live. A Search profile gathers your content from your own site plus YouTube, Instagram, TikTok, X and Facebook into a single destination on Google, and the badge is a follow button you place on your own pages.
The editorial payoff is stated plainly in Google's guide: when readers follow your Search profile, the content linked from that profile becomes more likely to appear for those readers in Google Discover. That is a meaningful shift in kind. Discover has always been a surface you were selected for; a followed profile makes it partly a surface you are subscribed to. Audience you already earned on social platforms can now be routed into a Google-owned feed.
Eligibility, per Google's support documentation: at least 10,000 followers or subscribers on at least one of YouTube, Instagram, X or TikTok, you must be 18 or older, and Search profiles are currently available in the United States only. If you already hold an established knowledge panel and meet the bar, Google may have generated a profile for you to claim rather than create from scratch.
What to do differently: name an owner for the profile this week and get it claimed, then treat the linked social accounts as part of your distribution surface rather than as separate channels. What to stop doing: stop writing Discover off as unattributable luck in your planning documents. For a followed audience it now has a controllable input.
Refusing AI training no longer costs you search visibility
Cloudflare shipped a change on September 15, 2026 that removes a tradeoff writers and publishers have been arguing about for two years. In its post Have it both ways: stay discoverable in search while disallowing AI training, Cloudflare introduced a Disallow AI Training setting that publishes a no-training preference while leaving search indexing intact. Status: live for all customers on all plans as of that date.
The tradeoff existed because the largest operators run mixed-use crawlers — one crawler feeding both search and model training. Blocking it to keep your work out of training data also removed you from search. Cloudflare's new Accountable designation covers operators that meet four criteria, including a mechanism to opt out of AI training and an assurance that opting out will not affect traditional search results. Apple, Google and Microsoft qualify; Amazon, Anthropic, Meta and OpenAI qualify by running separate search and training crawlers.
For editorial teams this converts a technical default into a publishing decision that belongs to you rather than to your infrastructure. Whether your original reporting, proprietary benchmarks and first-hand testing are available as training data is now a choice you can make without paying for it in organic traffic. Raise it with whoever owns your CDN, and make the call deliberately per property rather than inheriting it.
What to stop doing: stop citing 'we would lose Google traffic' as the reason the AI-training question cannot be revisited. As of September 15 that reason no longer holds for Accountable operators.
Ranking systems: nothing shipped, and that is worth stating
There is no confirmed Google core update, spam update or Discover update in flight. The Search Status Dashboard showed no incidents for crawling, indexing, ranking or serving as of its last update at 23:03 PDT on September 17, 2026, and the Search Central documentation changelog records no ranking-related entry after September 16. The Search Central Blog has published nothing since September 9.
This matters because volatility chatter tends to fill the vacuum. If your rankings moved this week, the evidence points at your own changes, at seasonal demand, or at SERP layout shifts — not at an algorithm update you can wait out. Diagnose accordingly rather than pausing planned work in anticipation of a rollback.
Unconfirmed: local panels rendering as AI Overviews, Discover missing on desktop
Two community reports surfaced on September 17 via Search Engine Roundtable and are logged here as unconfirmed, with no Google announcement or documentation change behind either. First, local business knowledge panels appearing as AI-powered overviews with expandable chat. Second, Google Discover on desktop, rolled out in 2025, no longer appearing on desktop Google.com.
Neither is actionable yet and neither should change a brief this week. Both are worth a manual spot-check if local search or Discover referrals are material to you, because either would alter how your content is surfaced and attributed. Treat any traffic movement in those two areas as a hypothesis to verify in your own analytics, not as a confirmed platform change.
Apply to your next brief
- Claim your Google Search profile if you clear 10,000 followers on YouTube, Instagram, X or TikTok, and assign a named owner for it — US properties only for now.
- Add the Search profile badge to article templates and the site footer once the profile is claimed, and brief writers to mention the follow option in author bios.
- Put the AI-training question on this week's agenda with whoever owns your CDN: opting out no longer costs search visibility with Accountable operators.
- Do not attribute this week's ranking movement to a Google update — none is running. Look at your own publishing changes and at seasonal demand first.
- Keep the local-knowledge-panel and desktop-Discover reports out of client reporting and strategy decks until Google documents them.
- Keep first-hand testing, original data and named author credentials in the brief: they remain the assets that get quoted by AI answer surfaces and are the reason a training opt-out is worth making deliberately.
2. SEO for Developers
The lead engineering change is Cloudflare's September 15 crawler-policy split, which changes defaults for new zones and can block AI agents on ad-carrying pages without anyone touching a repository — check what your CDN is serving before you trust your committed robots.txt. In the 24-hour window itself, the substantive change was Next.js correcting its own bots-and-crawlers caching guidance on September 17, which documents a real 500-error failure mode under Partial Prerendering.
Cloudflare splits AI training from search, and changes defaults for new zones
Date: September 15, 2026. Status: live, all plans, all customers. Breaking for new zones; non-breaking but behaviour-changing for existing ones. Cloudflare's Accountable mixed-use crawler post introduces a Disallow AI Training setting, configured under Domain Security Settings in the dashboard, which publishes a no-training preference in robots.txt while preserving search indexing. It blocks all training crawlers except those from Accountable mixed-use operators — Googlebot, Bingbot and Applebot continue to serve search. The separate Block setting removes them entirely.
The defaults are the part that will bite you. New domains without ad monetization get Training set to Allow. New domains with ad monetization get Training set to Disallow AI Training, and Agent set to Block on pages carrying ads. Existing customers were migrated automatically to preserve practical effects. Symptom if ignored: an agent-driven fetch of a monetized page returns a block rather than your HTML, and you will look for the cause in your application rather than in the dashboard.
This is also the surface where a CDN silently overrides repository intent. Bot Preference Sync, shipped August 21, 2026, generates robots.txt content from the AI crawler policy set in the dashboard and prepends it to your existing file between BEGIN and END markers. Your committed public/robots.txt is therefore not necessarily what Googlebot reads. Diff the served file against the repository before you debug anything crawl-related.
#!/usr/bin/env bash
# Compare the robots.txt you ship with the robots.txt Cloudflare serves.
set -euo pipefail
SITE="https://example.com"
curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1)" "$SITE/robots.txt" > /tmp/served.txt
# A Cloudflare-generated block is prepended between BEGIN/END markers.
if grep -qi "BEGIN" /tmp/served.txt; then
echo "WARNING: CDN-managed block present. Repo robots.txt is not authoritative."
sed -n '1,40p' /tmp/served.txt
fi
diff -u public/robots.txt /tmp/served.txt || echo "Served file differs from repo."
Per-operator detail from the same post, worth recording because the enforcement dates differ: Googlebot honours a Google-Extended disallow in robots.txt plus a webmaster portal toggle; Applebot honours Applebot-Extended, with a URL-level inspection tool promised next year; Bingbot's robots.txt support is targeted for early 2027 and currently relies on the NOARCHIVE meta tag. Keep training, search and user-triggered fetchers as three separate decisions — OpenAI's bot documentation still splits GPTBot, OAI-SearchBot, OAI-AdsBot and ChatGPT-User along exactly those lines.
Next.js rewrites its bots-and-crawlers caching guidance, and documents a 500
Date: merged September 17, 2026, in pull request #98782, shipped in the v16.4.0-canary.35 tag the same day. Non-breaking as a code change — it is documentation — but it corrects a misconception that was steering configuration, so treat the audit as urgent.
The previous guidance claimed all bots skip the static shell. That was wrong. Only HTML-limited bots get that treatment. The reason matters: with Partial Prerendering, metadata can resolve dynamically after the shell has loaded, which places the tags in the document body rather than in the head. Bots that require metadata in the head are therefore served a dynamic render instead of the shell.
The failure mode is now documented explicitly: if build-time prerendered data is unreachable at request time, rendering fails and the affected bots receive a 500. Symptom if ignored — Search Console reports server errors on URLs that load correctly in a browser, because only the HTML-limited bot path breaks. The setting is htmlLimitedBots in next.config.ts. The default list already covers Mediapartners-Google, AdsBot-Google, Google-PageRenderer, Bingbot, Twitterbot and Slackbot.
The footgun is that setting htmlLimitedBots overrides the default list entirely rather than extending it. If you added one internal crawler to that regex at any point, you silently dropped Bingbot and the Google crawlers from blocking metadata. Grep for it today.
import type { NextConfig } from 'next'
// htmlLimitedBots REPLACES the Next.js default list — it does not extend it.
// Re-state the defaults you still need, then add your own.
const config: NextConfig = {
htmlLimitedBots:
/Mediapartners-Google|AdsBot-Google|Google-PageRenderer|bingbot|Twitterbot|Slackbot|MyInternalCrawler/i,
}
export default config
Schema.org 30.1 adds Digital Product Passport and return-policy vocabulary
Date: September 16, 2026. Status: stable release, published to schema.org/version/latest and logged on the releases page. Non-breaking — additive vocabulary only. The release adds DigitalProductPassport, EnvironmentalProductDeclaration and DeclarationOfConformity as certification types, expands the merchant return-policy vocabulary, and extends IPTCDigitalSourceEnumeration and MediaManipulationRatingEnumeration for labelling algorithmic and synthetic media.
Read the caveat before you ship markup: a Schema.org vocabulary release is not a Google rich result. Google's feature guides and eligibility are a separate track, and nothing in Google's documentation changelog references 30.1. Adding these types is safe and can help entity resolution in AI answer surfaces, but do not brief anyone that it unlocks a SERP feature. The EU Digital Product Passport regime is the real near-term driver here — mandatory passports begin applying to specified battery categories in February 2027, so ecommerce teams in scope should start modelling now.
<!-- JSON-LD emitted into <head>. Schema.org 30.1 vocabulary. -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example Battery Pack",
"sku": "EBP-1200",
"hasCertification": {
"@type": "DigitalProductPassport",
"issuedBy": { "@type": "Organization", "name": "Example Manufacturing Ltd" }
},
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"applicableCountry": "US",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"returnFees": "https://schema.org/FreeReturn"
}
}
</script>
Ship the Search profile badge as a component, not a pasted snippet
Date: September 16, 2026, per the Search profile badge guide. Status: live, US only. This is the engineering half of the lead editorial story. Google specifies the link target format, the asset, and hard accessibility constraints: keep the clickable target at least 48 x 48 dp on Android and 44 x 44 px on iOS and web, and do not stretch, distort, rotate or recolour the icon.
Build it once as a component with the handle injected from configuration. Hand-pasted markup across templates is how the aria-label gets dropped on half the pages and how the touch target ends up at 24 px inside a footer row. Use the official asset from Google's ZIP rather than re-exporting the icon yourself, because recolouring it breaches the stated brand requirements.
<!-- Minimum target: 44x44 px on web. Do not recolour or distort the asset. -->
<a
href="https://profile.google.com/@your-handle"
aria-label="Find us on Google Search"
style="display:inline-flex;align-items:center;justify-content:center;
min-width:44px;min-height:44px"
>
<img src="/badges/google-search-badge.svg" alt="Google Search" width="160" height="40" />
</a>
Astro 7.3.3 fixes a trailing-slash redirect body
Date: September 16, 2026, in the Astro releases feed. Status: published. Non-breaking patch. The fix corrects a trailing-slash redirect whose response body pointed at the incoming URL instead of the redirect target, so the HTML body now carries the correct destination path.
The status code and Location header were already correct, so most crawlers were unaffected — this matters for the clients that read the body of a redirect response, and for anyone auditing redirect chains with a tool that parses bodies. Low severity, but it is a free correctness win if you are already on 7.3.x. The same batch fixed prerendered Cloudflare pages rendering as corrupted objects under certain compatibility settings, which is worth knowing if you deploy Astro to Cloudflare.
Ship today
- Diff your served robots.txt against the repository copy. If Cloudflare's Bot Preference Sync is prepending a managed block, your committed file is not authoritative.
- Open Domain Security Settings in Cloudflare and record the Training and Agent values for every zone. New monetized zones now default to blocking agents on ad-carrying pages.
- Grep for htmlLimitedBots in next.config.ts. If it is set, re-add the default user agents — the option replaces the default list rather than extending it.
- Check Search Console for 500s on URLs that render correctly in a browser; under Partial Prerendering this is the documented symptom of build-time data being unreachable at request time.
- Build the Search profile badge as a single component with a 44 px minimum target and the official asset, then roll it into article templates and the footer.
- If you sell into the EU, model DigitalProductPassport and the expanded return-policy types now — additive, safe to ship, and ahead of the February 2027 battery deadline.
Method and scope
Window: 24 hours to 06:00 UTC on September 18, 2026. Items dated September 15 and 16 are included where they are still rolling out and carry same-day engineering consequences; each carries its true date above. Sources are primary throughout — vendor documentation, release tags, pull requests and status dashboards. Industry blogs were used only to detect candidates, and the two community reports in Section 1 are labelled unconfirmed and excluded from both action blocks. All timestamps are as published by the source.
Comments
Share your thoughts and join the conversation



