Daily SEO Note — October 14, 2026: Bing Clusters AI Citations Into Topics

Audit window: 2026-10-13 06:00 UTC to 2026-10-14 06:00 UTC. Every item below traces to a primary source with a date and a rollout status; trade blogs were used for detection only. Unconfirmed reports are labelled and kept out of the action blocks.

1. SEO for Content Writers

The one verified editorial change today came from Microsoft, not Google: Bing Webmaster Tools now clusters the AI-search queries that cite your site into topics, and names the queries where other sites get cited and you do not. Google's Search Status Dashboard logged no ranking, crawling, indexing or serving incident in the window, and the Search Central blog and documentation changelog both published nothing new.

Bing clusters your AI citations into topics, and names the gaps

On 13 October 2026 Microsoft shipped Topics Portfolio as a beta tab inside the AI Performance report in Bing Webmaster Tools. Instead of listing grounding queries one by one, it groups the queries where your site is cited into broad themes, and gives each theme three figures: Topic Size (total citations across all sites for that theme), Sites Cited (how crowded the theme is) and Queries (how many distinct grounding queries it contains).

The part that changes editorial planning is Top Opportunity Queries. Below the topic table, Bing lists the strongest queries across your portfolio where other sites appear in AI answers and yours does not, with citation volumes shown as ranges. Each topic also has its own detail page splitting "Your Grounding Queries" from "Opportunity Queries", over a one-, two- or three-month window. That is a gap list you can hand to a writer without any further analysis.

Rollout status is beta, and it only appears where there is enough data, so smaller sites may see a short list or no tab at all. Microsoft is explicit that the numbers are approximate and that topic labels are AI-generated: it asks you to treat them as "directional signals for planning, not as a precise ledger." Branded competitor queries can also leak into the opportunity list, so the list needs a human pass before it becomes a brief.

Affects all content, with the most value for publishers doing topic-level planning. The concrete instruction: before writing your next brief, open the Topics Portfolio tab, take the opportunity queries for the one topic you most want to own, and build the outline around answering those queries directly. Stop treating AI-citation reporting as a query-by-query audit, and stop quoting Topic Size or Sites Cited as hard numbers in client reporting.

Google's own podcast explains how PDFs reach Search and AI answers

Episode 115 of Search Off the Record, "PDFs in Search: Indexing, AI & Pitfalls," was published on 13 October 2026 with Martin Splitt and John Mueller. It is guidance, not a rollout: nothing about PDF handling changed on this date. What it does is confirm the pipeline. Google runs PDFs through a converter that produces an HTML representation, and from there the same indexing and ranking systems handle them as any other page. Converted PDFs can therefore surface in AI Overviews and AI Mode.

Two consequences matter for editorial. First, the text has to be real text: a rasterised or scanned PDF has nothing for the converter to extract, so it will not rank and will not be quoted in an AI answer. Second, images embedded in a PDF have no standalone URLs, so they cannot be processed into Google Images the way an image on an HTML page can. A chart that only exists inside a PDF is invisible as an image asset.

The episode also went over links, which are preserved and crawled from inside the PDF, and over size limits, which the hosts could not state on air. Google's Googlebot documentation remains the citation of record there: 2 MB for HTML and other supported text-based files, 64 MB for PDFs, measured uncompressed.

Affects any content type that ships as a PDF: whitepapers, research, manuals, menus, prospectuses. The instruction for the next brief is to plan the HTML page as the canonical version and the PDF as the download, not the reverse. Stop publishing scanned or image-only PDFs as the primary version of a resource, and stop relying on a PDF to carry images you want indexed.

Prescription drug ads move into AI Mode and AI Overviews in the US

On 13 October 2026 Google confirmed on the record, via a spokesperson quoted by Adweek, that ad eligibility in AI Mode and AI Overviews has "recently expanded to include certain pharmaceutical products," including branded prescription drugs. Rollout status is a limited US test, running as standard text and Shopping ads labelled "sponsored" rather than in experimental AI ad formats.

Google's existing healthcare and medicines policy is the policy of record and still applies in full, certification requirements included. Nothing here changes organic eligibility, ranking or citation behaviour: this is paid inventory appearing alongside AI answers, not a quality-system change.

Affects one vertical: US health and pharma publishers. The editorial instruction is narrow but real. If you publish health content for a US audience, expect less visible real estate above and inside AI answers on branded-drug and condition-plus-treatment queries, and separate paid displacement from organic decline before you rewrite anything. Do not re-brief a page on the assumption it lost rankings when the surface simply gained ads.

Unconfirmed, no primary source. Trade reports describe Search Console's Performance report date picker breaking on 13 October with an end date pinned to 1969 and then being fixed the same day, and a Google Trends anomaly placing Wyoming first across unrelated queries. A Google job posting describing Discover as a future "proactive, hyper-personalized concierge experience" was also circulating. Google published nothing on any of the three. If you pulled Search Console or Trends data for a rewrite decision on 13 October, re-pull it before acting; these items are excluded from the checklist below.

Apply to your next brief

• Open the Topics Portfolio tab in Bing Webmaster Tools and pick one topic to own; build the next outline from its Opportunity Queries rather than from a keyword list.
• Add a line to every brief naming the AI-answer format the piece should win: a definition, a comparison table, or a direct answer in the first paragraph.
• For any PDF deliverable, brief the HTML page first and treat the PDF as a secondary download; require selectable text, never a scan.
• Move charts and data visuals out of PDFs and onto HTML pages with real alt text if you want them to exist as image assets.
• Report AI-citation figures from Bing as directional ranges, never as exact counts, and strip competitor brand queries out of opportunity lists before briefing.
• US health and pharma desks: annotate the 13 October ad expansion in your reporting so paid displacement in AI answers is not mistaken for an organic drop.
• Re-pull any Search Console or Google Trends export taken on 13 October before using it to justify a rewrite or a pruning decision.

2. SEO for Developers

One change today is worth a same-day pull request: Cloudflare's Real User Monitoring now breaks LCP into four phases and INP into three, in the dashboard and in the GraphQL Analytics API, which turns "our LCP is bad" into a specific phase you can fix. Everything else in the window is a canary-channel fix or an automatic edge change you should verify rather than deploy.

Cloudflare RUM ships LCP and INP sub-part metrics

Shipped 13 October 2026 in Cloudflare Web Analytics. Non-breaking and additive. LCP is now split into Time to First Byte, resource load delay, resource load duration and element render delay; INP is split into input delay, processing duration and presentation delay. Separately, connection time is split into connection-without-TLS and TLS handshake time, while the combined connectionTime field is retained.

The symptom if you ignore it is simply continued guesswork: you keep optimising images when the real cost is element render delay, or you keep splitting bundles when the real cost is presentation delay. Until now RUM gave you a single LCP number, which told you a template was slow but not which phase to attack.

The sub-parts appear in the Core Web Vitals section of the Real user monitoring report, and the connection split in the Page Load section. In the GraphQL Analytics API the Web Vitals sub-parts live on the rumWebVitalsEventsAdaptiveGroups node and the connection split on rumPerformanceEventsAdaptiveGroups, with percentile suffixes P25, P50, P75, P90, P95, P99 and P999 — for example lcpResourceLoadDelayP75 and inpInputDelayP75. Values are in microseconds, and a negative value means the data is not available, which you must handle before charting.

# Pull LCP/INP sub-parts at P75 from Cloudflare's GraphQL Analytics API.
# Docs: https://developers.cloudflare.com/analytics/graphql-api/
# Values are MICROSECONDS; a negative value means "not available".
# Introspect the node before wiring a dashboard — field placement
# under `quantiles` follows Cloudflare's adaptive-groups convention.
set -euo pipefail

curl -sS https://api.cloudflare.com/client/v4/graphql \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data @- <<'JSON' | jq '.data.viewer.zones[0]'
{
  "query": "query S($zone:String!,$since:Time!,$until:Time!){viewer{zones(filter:{zoneTag:$zone}){rumWebVitalsEventsAdaptiveGroups(limit:1,filter:{datetime_geq:$since,datetime_lt:$until}){quantiles{lcpResourceLoadDelayP75 lcpResourceLoadTimeP75 lcpElementRenderDelayP75 inpInputDelayP75 inpProcessingDurationP75 inpPresentationDelayP75}}}}}",
  "variables": {
    "zone": "YOUR_ZONE_TAG",
    "since": "2026-10-07T00:00:00Z",
    "until": "2026-10-14T00:00:00Z"
  }
}
JSON

Map each phase to a fix rather than to a generic budget: time to first byte is cache and origin, resource load delay is discovery and preload, resource load duration is transfer size and priority, element render delay is main-thread and font blocking. Google's LCP and INP guides use the same phase breakdown, so the two line up directly.

Next.js canary fixes Turbopack edge route handlers under cacheHandlers

Next.js v16.5.0-canary.10 was tagged on 13 October 2026. Pre-release only, so nothing here is breaking for anyone on stable. Three entries matter if you run canary: PR #100046 fixes Turbopack edge route handlers when cacheHandlers is configured, PR #100128 makes durable use cache ignore binding usage when traversing, and PR #96517 corrects the cache-handler documentation on updateTags durations and the Redis EX value for Infinity.

The documentation fix is the one with a real symptom outside canary. If you wrote a Redis-backed cache handler from the previous docs and passed an infinite expiry straight through as an EX value, Redis rejects the non-integer argument and the write fails — so entries you believe are cached forever are silently not cached at all. An infinite expiry has to become the absence of EX, not EX: Infinity.

// Custom cache handler for `use cache` / cacheHandlers.
// Redis rejects a non-integer EX, so an infinite expiry must omit EX
// entirely rather than pass `Infinity` through.
export default {
  async set(key, value, { expire } = {}) {
    const payload = JSON.stringify(value)

    if (expire === Infinity || !Number.isFinite(expire)) {
      await redis.set(key, payload)                       // no expiry
    } else {
      await redis.set(key, payload, { EX: Math.ceil(expire) })
    }
  },
}

Action is watch, not ship, unless you are already tracking canary. If you are, confirm edge route handlers still resolve after enabling cacheHandlers, and audit any cache handler for the Infinity-to-EX path above. Stable-channel sites should take only the Redis fix.

Cloudflare BYOIP subrequests now carry real end-user bot signals

Also 13 October 2026, and automatic with no configuration: Workers subrequests to Cloudflare-proxied hostnames on Bring Your Own IP ranges now keep their Workers context. They carry the CF-Worker header and the cf.worker.upstream_zone field, and Cloudflare treats them as Cloudflare-to-Cloudflare traffic rather than external internet traffic.

It is non-breaking by intent, but it changes the values your rules read. For affected BYOIP subrequests, Bot Management fields — bot score, verified bot status and JA3/JA4 fingerprints — now describe the original end-user connection instead of the internal hop between Cloudflare services. The symptom if you ignore it is a rule that was tuned against the old internal values quietly changing behaviour, in either direction: a crawler allow-list that stops matching, or traffic that previously tripped a false 403 now passing.

# Cloudflare WAF custom rule expressions.
# After 2026-10-13, bot fields on BYOIP subrequests describe the real
# end-user connection, so re-test any rule that reads them.

# 1. Skip bot challenges for your own Workers-to-origin subrequests.
(cf.worker.upstream_zone eq "example.com")

# 2. Keep verified search crawlers out of challenges — now scored
#    against the real client, not the internal hop.
(cf.bot_management.verified_bot and not http.request.uri.path contains "/api/")

# 3. Watch, do not block, before you trust the new values.
#    Set this to Log for one week and diff the match count.
(cf.bot_management.score lt 30 and not cf.bot_management.verified_bot)

Setting to change: your WAF custom rules and bot rules, not application code. Put any crawler-facing rule into Log for a week and compare match counts against the previous week before leaving it on Block.

The PDF pipeline, in byte limits

The 13 October Search Off the Record episode on PDFs is guidance rather than a change, but it has an engineering half worth acting on, because the hosts could not state the crawl size limits on air. The Googlebot documentation is the setting of record: 2 MB for HTML and other supported text-based files, 64 MB for PDFs. The limits apply to uncompressed bytes and include the HTTP header, so compression does not buy you room, and each referenced resource gets its own limit — with PDFs as the exception.

The symptom if ignored is a quiet truncation rather than an error. Googlebot stops the fetch at the cutoff and processes only the bytes it already has, so a template that inlines a large JSON payload or a long embedded state blob can push canonical tags, hreflang or structured data past 2 MB and out of the crawl. Nothing in Search Console reports this as a failure.

# Fail the build when a rendered document exceeds Googlebot's cutoff.
# 2 MB for HTML, 64 MB for PDF, uncompressed, header included.
# Source: developers.google.com/search/docs/crawling-indexing/googlebot
set -euo pipefail

HTML_LIMIT=$((2 * 1024 * 1024))
PDF_LIMIT=$((64 * 1024 * 1024))
status=0

while read -r url; do
  # --compressed decompresses, so wc -c counts uncompressed bytes.
  bytes=$(curl -sSL --compressed "$url" | wc -c)
  case "$url" in
    *.pdf) limit=$PDF_LIMIT ;;
    *)     limit=$HTML_LIMIT ;;
  esac
  if [ "$bytes" -gt "$limit" ]; then
    printf 'OVER LIMIT: %s (%s bytes > %s)\n' "$url" "$bytes" "$limit" >&2
    status=1
  fi
done < sitemap-urls.txt

exit "$status"

Add the check to CI against your sitemap, and route PDF deliverables through the same step with the 64 MB bound. For anything you want ranked, ship an HTML page and link the PDF, since the converter's HTML representation is what the indexing systems actually see.

Nothing else verified in the window. web.dev, the Chrome developer blog, Astro, Nuxt, SvelteKit, Lighthouse, web-vitals and Schema.org all published nothing between 13 October 06:00 and 14 October 06:00 UTC, and no new GitHub advisory landed for an SEO package, sitemap generator or crawler dependency.

Ship today

1. Enable the Cloudflare RUM beacon if it is off, then pull LCP and INP sub-parts at P75 and record a baseline per template before changing anything.
2. Patch any Redis-backed cache handler so an infinite expiry omits EX rather than passing Infinity, which Redis rejects outright.
3. Set every crawler-facing WAF and bot rule to Log for one week and diff match counts, because BYOIP subrequest bot fields now describe the real client.
4. Add the uncompressed size check to CI against your sitemap: 2 MB for HTML, 64 MB for PDF.
5. If you run Next.js canary, verify edge route handlers resolve with cacheHandlers enabled; if you run stable, take no action beyond the Redis fix.