Daily SEO Note — November 7, 2026: Offers You Did Not Write Can Reach Your Business Profile

Window for this edition: the 24 hours to 06:00 UTC on November 7, 2026. Today is a Saturday, so the weekend extension — which applies on Mondays — does not kick in. Every timestamp below is UTC unless the source states otherwise.

Start with what did not move. Google's Search Status Dashboard reports no incidents across Crawling, Indexing, Ranking and Serving, last updated 22:02 PST on November 6, 2026. Its incident history confirms there is no ranking update in flight: the most recent ranking event is still the September 2026 spam update, which began 2026-09-24 16:15 and ended 2026-10-08 08:00. The Search Central documentation changelog has published nothing since October 26, 2026. The newest Search Central blog post is the Search Central Live Zurich announcement, which carries no guidance for site owners. The Bing Webmaster blog is still headed by the Topics Portfolio beta from October 13, 2026.

Everything below arrived from a help document, a status dashboard, and a pull request.

SEO for Content Writers

The most consequential editorial change today is that Google has documented, in its Business Profile help centre, that offers submitted by third-party partners can appear on your profile — and that offers can surface inside AI Overviews. That is promotional copy you did not write, attached to your brand, inside an AI answer surface, with a removal process that runs on someone else's clock.

Partners can attach offers to your Business Profile, and offers can show inside AI Overviews

Google's Manage offers on your Business Profile help page was surfaced on November 6, 2026. Rollout status: live, with the page carrying the caveat that "This feature is available only in select regions and languages, and may not be available for all users."

The page names two sources for the offers that appear on a profile. The first is authorised third-party partners — providers that send offers data to Google and that are required to have "an active business relationship" with the business. The second is promotions Google identifies itself, which includes the Offers Posts you publish and, importantly, offers Google finds through your linked social media profiles. The surfaces are named too: offers render as collapsible chips beside or below the "Order online" or "Reserve a table" buttons on the Search placesheet, and the page states plainly that "Users can be shown offers when interacting with the Search AI Overview."

Who it affects: any business with a Google Business Profile in an eligible region, most sharply retail, restaurants and local services — the verticals where partner integrations and aggregators are thickest. The point that matters for an editorial team is the second source. A discount you posted to a linked social account and forgot about is eligible to become a Google-surfaced offer, and from there it is eligible to be shown in an AI Overview. Your social backlog is now promotional inventory for Search.

What to do differently in the next brief: treat the Business Profile as a surface you co-author rather than one you own. Add an offers review to the same cadence that already covers hours, categories and photos, and check what is actually displayed rather than what you submitted. On the half you do control, write Offers Posts with explicit start and end dates and plain terms, because that is the material Google's own detection has to work with. Then prune linked social promotions when they expire, which is a step most content calendars do not have at all.

What to stop doing: stop describing the Business Profile as owned media in strategy documents. It is syndicated, and the correction path is bureaucratic. Google's documented route is to contact Business Profile Support, type "Remove Offers" when prompted, choose "Fix Posts" as the category, and supply the provider's name, a screenshot, and a statement that you have no relationship with them. Providers "must remove third-party offers from a profile within 5 business days," and if that lapses you escalate through the Violation Form. Five business days is a week of a wrong price in an AI Overview, so the discovery step is the one worth automating attention on.

A Merchant Center and Feeds outage ran eight and a half hours, and Google posted about it six hours in

The Merchant Center Status Dashboard records an incident affecting Merchant API, Merchant Center and Feeds that began at 2026-11-06 04:30 and ended at 2026-11-06 13:00. Rollout status: resolved. The dashboard carries exactly one update, posted at 10:26 on November 6 — "We're investigating reports of an issue with Merchant API, Merchant Center, and Feeds. We will provide more information shortly." No follow-up note was published; the resolution is recorded only as the incident's end time.

The editorial instruction here is a negative one, and it is worth writing down because the alternative is expensive. If product content, prices or promotions went missing from Search yesterday, or if the Merchant Center interface loaded without data, that was infrastructure. It was not your titles, not your descriptions, not a quality problem with the feed copy. Do not open a rewrite, do not re-run a bulk description job, and do not let a drop in that window enter a monthly report as a content finding.

The second lesson is about the dashboard itself. Google's public notice landed five hours and fifty-six minutes after the start time it later recorded, and merchant forums were describing the symptoms before the notice appeared. A status page is confirmation, not detection. When a writer or merchandiser reports that something has vanished, the absence of a dashboard entry is not evidence that nothing is wrong.

Messaging moves to the front of the Maps listing

Google's monthly Small Business Bulletin, relayed in the Google Business Profile Help forums, announced that messaging has expanded to Google Maps on both Android and iOS, with a "prominent Message button right next to 'Call'" on the listing. Previously, as the post puts it, "finding chat on Maps required scrolling deep down into your profile." It was reported on November 6, 2026. Rollout status: rolling out on both platforms. Messages route to the channel the business already uses, including WhatsApp and SMS, and you can confirm which channel is linked through the Business Profile messaging settings.

For local content this moves the first contact off your website. A location page whose conversion path ends at a contact form is now competing with a button two taps away on a surface you do not control. The brief should change accordingly: the job of a local page shifts from capturing the enquiry to being the thing that makes the enquiry worth sending, and the page should answer the questions that otherwise become the opening message — availability, pricing ranges, what to bring, how long it takes.

What to stop doing: stop writing local pages whose only call to action is a form that duplicates a channel Google now surfaces more prominently than you do.

Unconfirmed: a "Claim your business in ChatGPT" surface

A screenshot posted to LinkedIn by Juozas Kaziukėnas and reported on November 6, 2026 at 10:32 ET shows a "Claim your business in ChatGPT" banner, described as part of a broader Business Hub. The reporting says it would chart daily impressions — how often a business appears in ChatGPT responses — and clicks through to the site, with no prompt-level data, no user data and no competitor benchmarking, and that access requires verified ownership, for example by connecting a Shopify store.

There is no OpenAI announcement and no help page, so this is logged as unconfirmed and kept out of the checklist below. If it ships as described, the significant part for an editorial team is the shape of the metric, not its existence: impressions and clicks without prompts tells you that you were cited and gives you nothing about why. The content signal would still have to be inferred from the pages that earn the citations, which is the same work as today.

Unconfirmed: AI Mode asking "Continue with this search?"

Reported on November 6, 2026, AI Mode has been seen showing a "Continue with this search?" interstitial carrying the warning that "Malicious queries could result in unsafe or harmful actions." It was observed on returning to a recent AI Mode search rather than on a fresh query, and the reporter reads it as friction aimed at bots and scrapers. Google has not commented.

If that reading is right, the editorial consequence is about your data rather than your pages. Third-party AI Mode visibility and share-of-voice datasets are built by querying AI Mode at volume. Friction on exactly that path thins the sample. Treat vendor AI Mode numbers from this period as directionally interesting and stop quoting them to two decimal places in client decks.

Apply to your next brief

• Add a Business Profile offers check to the same review cadence as hours and categories, and verify what is displayed rather than what you submitted. Offers can reach AI Overviews.
• Audit linked social media accounts for expired promotions. Google can pick those up as offers, so a stale social post is now a Search liability.
• Give every Offers Post an explicit start date, end date and plain terms, so the material Google detects is accurate.
• Write the third-party offer removal path into the runbook now: Support, type "Remove Offers", category "Fix Posts", supply the provider name and a screenshot, then escalate via the Violation Form if the five-business-day window lapses.
• Exclude the 2026-11-06 04:30 to 13:00 UTC window from any content-performance read on product or offer pages, and do not assign a rewrite to a drop inside it.
• Rework local page CTAs on the assumption the first contact is a Maps chat, not your form. Answer the questions that would otherwise be the opening message.
• Hold the ChatGPT business dashboard and the AI Mode interstitial out of client decks until there is an announcement from OpenAI or Google.

SEO for Developers

One engineering change landed in the window and it is not in a stable release yet: Next.js fixed Link response headers compounding on every background revalidation of an ISR page when cacheComponents is enabled. Alongside it, the Merchant API outage is worth a monitoring change rather than a code change. Everything else on the beat was quiet, and the quiet is itemised below rather than padded.

Next.js stops Link headers compounding on every ISR revalidation

Identifier and date: PR #100960 was merged into canary on November 6, 2026, and shipped in v16.5.0-canary.43, published to npm at 2026-11-06 23:51:19. Rollout status: canary only. Latest stable remains 16.4.5 from November 3, so there is nothing to upgrade to today — this is a detection and verification item, and it is on this list because cacheComponents stabilised in 16.0.0 as a top-level option, which means the affected configuration is the recommended path on Next 16 rather than an experimental corner.

The fix is non-breaking. The bug is the damaging part, and the symptom is precise. With cacheComponents: true, a Link header set in next.config.js headers() or by middleware was duplicated on any ISR page that also emitted a React preload Link — the common trigger being an <img fetchPriority="high">. Each background revalidation appended another copy. On a cache MISS, both the config Link and the preload Link came back twice. The count grows monotonically with the number of regenerations, so a page that revalidates hourly accumulates quietly for weeks.

The root cause explains why nothing in your HTML would show it. prerenderToStream handled React's onHeaders by writing each value to the live response and then snapshotting res.getHeader(name) into metadata.headers. That snapshot became the cache entry's headers and therefore included values the render never produced — the config Link, and Link values replayed from the previous cache entry. Because app-page-runtime appends cached headers to every response after the config headers are applied, each regeneration stored and then served one more copy. The fix narrows metadata.headers to only the values the render itself produces, and has callers apply them once. One behaviour change worth knowing: an RSC segment-prefetch response that triggers a fresh render no longer includes the preload Link.

This matters on this beat because Link: rel=preload headers are consumed before the HTML parser sees a byte, so duplicates multiply the preload set and compete for bandwidth against the resource the preload was meant to prioritise — an LCP regression that profiles as a mystery. Worse, header blocks that grow without bound eventually meet a CDN or proxy header-size limit, and what that returns to the client is an error rather than a page. The client in question includes Googlebot. The setting to change is nothing in your config; the thing to change is that you check, from outside, across more than one revalidation.

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  // Stable since 16.0.0. This is the configuration affected by #100960.
  cacheComponents: true,
  partialPrefetching: true,
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          // A config Link like this is the one that got duplicated,
          // once more on every background revalidation.
          { key: 'Link', value: '</fonts/inter.woff2>; rel=preload; as=font; crossorigin' },
        ],
      },
    ]
  },
}

export default nextConfig

#!/usr/bin/env bash
set -euo pipefail
# Duplicated Link headers are invisible in HTML. Count them across
# several revalidations: the count must not grow.
URL="${1:?usage: check-link-headers.sh https://example.com/product/abc}"
ROUNDS="${2:-6}"

for i in $(seq 1 "$ROUNDS"); do
  n=$(curl -sS -o /dev/null -D - "$URL" | grep -ci '^link:' || true)
  bytes=$(curl -sS -o /dev/null -D - "$URL" | grep -i '^link:' | wc -c)
  cache=$(curl -sS -o /dev/null -D - "$URL" \
    | grep -i '^x-nextjs-cache:' | tr -d '\r' || echo 'x-nextjs-cache: -')
  printf 'round %-2s link-headers=%-3s bytes=%-6s %s\n' "$i" "$n" "$bytes" "$cache"
  sleep 5
done
# Fail the check if the final count exceeds the first.

The Merchant API outage is a monitoring change, not a code change

Identifier and date: incident t9PYzTMMb6MzqB3zAuES on the Merchant Center Status Dashboard, affecting Merchant API, Merchant Center and Feeds, from 2026-11-06 04:30 to 13:00. Rollout status: resolved, with no post-incident note published.

Non-breaking, but the symptom if you ignore it recurs on the next one, and the dashboard history shows these are routine — comparable Merchant API incidents are recorded in February, April, June and August 2026. The operational problem is the notice latency. The incident's recorded start was 04:30; the only public update went up at 10:26, five hours and fifty-six minutes later. Any pipeline whose alerting is "check the dashboard" was blind for the first six hours, and any nightly feed push scheduled inside that window either failed or silently wrote nothing.

The thing to change is your Merchant API job's alerting and retry posture. Two concrete settings: alert on feed freshness measured from your own side rather than on job exit status, because a job that completes after swallowing API errors exits zero; and make a failed scheduled push retry on backoff into the next window instead of skipping to tomorrow. The dashboard is still worth polling — it publishes machine-readable JSON — but as corroboration that fires after your own monitor, not instead of it.

#!/usr/bin/env python3
"""Alert on feed staleness first, Google's dashboard second."""
import json
import sys
import urllib.request
from datetime import datetime, timedelta, timezone

DASHBOARD = "https://merchants.google.com/status/incidents.json"
MAX_FEED_AGE = timedelta(hours=6)


def fetch_json(url: str):
    req = urllib.request.Request(url, headers={"User-Agent": "feed-monitor/1.0"})
    with urllib.request.urlopen(req, timeout=30) as resp:
        return json.load(resp)


def open_incidents():
    out = []
    for inc in fetch_json(DASHBOARD):
        # An incident with no end time is still running.
        if not inc.get("end"):
            out.append(inc.get("external_desc", "unknown incident"))
    return out


def main(last_successful_push_iso: str) -> int:
    now = datetime.now(timezone.utc)
    age = now - datetime.fromisoformat(last_successful_push_iso)

    problems = []
    # Your own signal fires first and does not depend on Google posting.
    if age > MAX_FEED_AGE:
        problems.append(f"feed stale: last successful push {age} ago")
    # The dashboard is corroboration, added to the same alert.
    for desc in open_incidents():
        problems.append(f"google reports open incident: {desc}")

    if problems:
        print("; ".join(problems), file=sys.stderr)
        return 1
    print(f"ok: feed age {age}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main(sys.argv[1]))

Quiet: advisories, frameworks, performance, structured data and crawler policy

No SEO-relevant advisory landed in the window. The sixteen entries published to the GitHub Advisory Database on November 6, 2026 are dominated by LXD (ten advisories, several critical), with GeoNode, listmonk, the OSAC operator and Eclipse hawkBit making up the rest — nothing in a crawler, sitemap, metadata or CMS dependency, and nothing published at all on November 7 as of this window closing.

Frameworks are unchanged since yesterday's edition. Astro is still 7.4.7 and @sveltejs/kit still 2.70.4 and 3.1.1, all from November 5; Nuxt remains 4.6.4; Next.js stable remains 16.4.5. On npm, no publish landed in the window for @astrojs/sitemap, @nuxtjs/sitemap, @nuxtjs/robots, next-sitemap, next-seo, nuxt-schema-org or schema-dts. Performance tooling is static: Lighthouse at 13.6.0 from October 27, web-vitals at 6.2.3, nothing new on the web.dev blog, and Core Web Vitals thresholds unchanged. Schema.org is still at version 30.1 from September 16, 2026.

Crawler policy is also where it was. Google's common crawlers documentation carries no change in the window, OpenAI's bots page documents the same four agents — OAI-SearchBot for search, GPTBot for training, ChatGPT-User for user-triggered fetches and OAI-AdsBot for ad landing-page safety checks — and Perplexity's documents PerplexityBot and Perplexity-User. Neither vendor publishes a dated changelog on those pages, so a scheduled diff of them is the only way to catch a change; today there is nothing to report. The Cloudflare changelog published four entries on November 6, covering AI Gateway key activity, Access passkeys, UEBA fast-flux detection and API token creation — none touching bots, cache rules or WAF. The Vercel changelog entries for November 6 are AI Gateway and tracing items with no SEO surface.

Ship today

1. Run an external Link header count against your highest-traffic ISR routes across several revalidations. If you are on Next 16 with cacheComponents: true and the count climbs, you have PR #100960's bug in production and there is no stable release carrying the fix yet — so cap the exposure by moving config-level Link preloads into the document for now.
2. Check your CDN and origin header-size limits against the current size of those header blocks, so you know how many more revalidations you have before a request starts failing.
3. Pin or track [email protected] in a non-production environment to confirm the fix against your own routes, and note the behaviour change: segment-prefetch responses that trigger a fresh render no longer carry the preload Link.
4. Change the Merchant API feed alert to fire on feed freshness measured from your own side rather than on job exit status, and give the scheduled push a backoff retry that survives a multi-hour upstream outage.
5. Add the Merchant Center status JSON as a secondary input to that alert, not the primary one — yesterday it was nearly six hours behind the incident's own recorded start.
6. Add a scheduled diff of the OpenAI and Perplexity bot documentation pages to your monitoring. Neither publishes a dated changelog, so a silent agent addition is otherwise invisible until it shows up in your logs.