Daily SEO Note — October 28, 2026: Google Tightens Favicon Crawl Rules as Lighthouse 13.6 Fails Throttled robots.txt

Audit window: 2026-10-27 06:00 UTC to 2026-10-28 06:00 UTC. Every item below traces to a primary source with a date and a rollout status. Community reports are labelled unconfirmed and excluded from the action blocks.

1. SEO for Content Writers

The one editorial change that matters today is Google's rewrite of its user-generated spam guidance, last updated October 26, 2026: Google now states plainly that posts from accounts with no platform reputation should be kept out of Search with a noindex rule until that reputation exists. Nothing in this window touched ranking systems. The Search Status Dashboard reported no incidents when checked at 06:04 UTC on October 28, and no October 2026 core update has been confirmed.

Google's user-generated spam guidance now asks you to gate new-account content

Google's guide to preventing user-generated spam (last updated 2026-10-26 UTC, live in documentation) now tells platforms to keep posts from users with no established reputation out of search results, for example with a noindex meta tag, and to allow indexing once the user has built reputation. It adds two more instructions: pages built for sharing, collaboration, or utility rather than public search should default to noindex, and links inside untrusted content should carry rel="nofollow" or rel="ugc".

This affects any property that renders reader-submitted text: comments, forums, member profiles, reviews, Q&A threads, and shared documents. It is not a ranking change and there is no algorithmic rollout attached to it. It is a policy clarification, and it moves the burden onto you to prove a contributor is trustworthy before Google sees their work.

What to do differently in the next brief: specify the indexing state for UGC templates by author lifecycle stage rather than by template. A profile page is not one thing to be indexed or not indexed; it is noindex for a day-one account and indexable for an established contributor, and the brief should say which. Add a standing monthly check of the Page Indexing and Search performance reports for spikes in indexed pages, impressions, or queries that do not match your platform's purpose, which is Google's own suggested detection method.

What to stop doing: stop treating "every profile and every thread indexable" as a traffic win, and stop shipping share or collaboration URLs as indexable by default. Both are now explicitly named as spam-surface risks rather than neutral choices.

No confirmed ranking update: this week's volatility is unconfirmed

The Search Status Dashboard showed no ranking, indexing, or serving incidents when checked at 2026-10-28 06:04 UTC; the page itself reported "No incidents" and was last updated 27 Oct 2026, 23:04 PDT. Google's documentation changelog lists no ranking-system entries for October 27 or 28 either. The last confirmed ranking event remains the September 2026 spam update.

Against that, community trackers reported volatility spikes on October 24 and again on October 27, and separately that Google is testing disabling clicks in the Discover sources section. Both are unconfirmed community reports with no primary source and no Google acknowledgement. Record them as unconfirmed in your own notes and do not brief against them.

What to do differently: nothing. That is the actionable instruction. Reactive rewrites against unconfirmed volatility consume the capacity you need for the scheduled work, and when the chatter turns out to be noise there is no way to recover the week. Hold the calendar.

Per-page AI bot traffic is now measurable, which changes how you pick refresh targets

Vercel shipped AI traffic insights to Observability on October 27, 2026 (live, additive). It reports request counts per verified AI bot and, editorially the useful part, separates crawlers fetching for indexing or training from assistant retrievals triggered by a user's question. It also lists the pages most often requested in Markdown and flags pages where AI bot requests return errors.

This affects all content on a site hosted on Vercel. Until now the question a writer actually cares about, which of my articles do assistants read when someone asks a question, had no first-party answer and was usually guessed at from third-party visibility tools. It now has one.

What to do differently: before you choose refresh targets for the next cycle, ask your engineer for the Observability to AI Traffic view and sort by assistant retrievals. Pages that assistants already fetch in response to user questions are your highest-leverage rewrites, because they are being read and quoted right now, and tightening a definition or adding a comparison table there changes what gets quoted. Pages returning errors to AI bots are a silent loss worth a ticket.

One consequence of the crawler policy in Section 2 that writers need to hold onto: OpenAI documents GPTBot, OAI-SearchBot, and ChatGPT-User as independent settings. Blocking training does not remove you from ChatGPT's search answers, and allowing search does not consent to training. Before you promise a stakeholder "AI visibility", find out which of those decisions your site has already made.

Apply to your next brief

• Specify the indexing state of every UGC surface by author lifecycle stage: noindex until the contributor has platform reputation, indexable after.
• Add rel="ugc nofollow" to the editorial spec for any template that renders reader-submitted links, rather than leaving it to QA.
• Default share, collaboration, and utility URLs to noindex in the brief itself.
• Add a standing monthly line: review Page Indexing and Search performance for impression or query spikes that do not match the site's purpose.
• Pull the AI Traffic view before locking refresh targets, and prioritise pages assistants already retrieve for user questions.
• Schedule no reactive rewrites against the October 24 and 27 volatility reports. They are unconfirmed.

2. SEO for Developers

Google changed its favicon requirements on October 27, 2026 to require that Googlebot be able to crawl the home page and follow redirects from there to the page where the favicon is declared. It is a crawl-path requirement, which means a redirect or a robots.txt rule can remove your favicon from results with no Search Console error to tell you. Lighthouse 13.6.0 shipped the same day and turns a rate-limited robots.txt or llms.txt into an outright audit failure.

Google's favicon guidelines now require a crawlable redirect path from the home page

Documentation change, favicon in Search guidelines last updated 2026-10-27 UTC, live. Breaking for any site that redirects its home page or blocks the favicon path. The guidelines now state that Googlebot "must be able to crawl the home page, follow any redirects from there to the page where the favicon is specified", and that "These URLs must not be blocked from crawling by a robots.txt file or by other means."

Symptom if ignored: your favicon stops appearing beside your result in Search and Discover. There is no Search Console report for this, so the failure is silent and you will usually hear about it from a stakeholder rather than a tool.

What to change: public/robots.txt must carry no Disallow covering the favicon URL or the host it is served from, and whatever handles your home-page redirect (middleware.ts, the redirects array in vercel.json, or a CDN rule) must resolve to the document that declares the icon. Two configurations break this in practice: a favicon served from an asset subdomain that sits behind a blanket Disallow, and a home-page redirect chain that passes through a 3xx hop Googlebot will not follow. Verify the whole chain rather than the final URL.

#!/usr/bin/env bash
# Google requires Googlebot to crawl / , follow redirects, and reach the favicon.
# Any non-2xx hop, or a robots.txt Disallow, drops the favicon from Search.
set -euo pipefail
SITE="https://example.com"

echo "== home page redirect chain =="
curl -sSIL "$SITE/" -o /dev/null \
  -w '%{http_code} -> %{url_effective}\n'

echo "== declared icon URL =="
ICON=$(curl -sSL "$SITE/" \
  | grep -oiE '<link[^>]+rel="[^"]*icon[^"]*"[^>]*>' \
  | grep -oiE 'href="[^"]+"' | head -1 | cut -d'"' -f2)
echo "icon: $ICON"

echo "== icon reachable? (must be 200) =="
curl -sSIL "${ICON:-$SITE/favicon.ico}" -o /dev/null -w '%{http_code}\n'

echo "== robots.txt rules mentioning the icon path =="
curl -sS "$SITE/robots.txt" | grep -iE 'disallow' || echo "no Disallow rules"

Lighthouse 13.6.0 fails the robots-txt and llms-txt audits on HTTP 429

Version Lighthouse v13.6.0, released 2026-10-27, stable. Breaking for CI. The release "fail robots-txt and llms-txt on HTTP 429" (#17295) changes a tolerated response into a failure: under 13.5.0 a throttled robots.txt passed the audit, and under 13.6.0 it does not. A companion fix, "do not throw when robots.txt or llms.txt content is null" (#17294), stops the audit crashing outright on an empty body.

Symptom if ignored: a site that rate-limits automated requests starts failing the robots-txt audit the moment CI picks up 13.6.0, and the SEO category score drops with no code change to blame it on. This is the failure mode that wastes an afternoon, because the regression arrives with a dependency bump rather than a deploy.

What to change: exempt /robots.txt and /llms.txt from rate limiting at the edge, whether that is a Cloudflare rate-limiting rule, a WAF skip, or a limit_req exclusion in your reverse proxy. Then assert both audits by name in Lighthouse CI so the next regression surfaces as a named failure instead of an unexplained score movement.

// Lighthouse 13.6.0 (2026-10-27) fails robots-txt and llms-txt on HTTP 429.
// Assert them by name so a throttled response is a named CI failure,
// not an unexplained SEO score drop.
module.exports = {
  ci: {
    collect: {
      url: ['https://example.com/'],
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        'robots-txt': ['error', { minScore: 1 }],
        'llms-txt': ['error', { minScore: 1 }],
        'canonical': ['error', { minScore: 1 }],
        'is-crawlable': ['error', { minScore: 1 }],
        'categories:seo': ['error', { minScore: 0.95 }],
      },
    },
  },
};

Lighthouse 13.6.0 safelists the RSL License directive, removing a false SEO failure

Same release, PR #17160 (merged 2026-10-09, shipped 2026-10-27). Non-breaking: it removes a false negative. Before this, a robots.txt carrying the License directive defined by RSL 1.0 was reported as an "Unknown directive", which failed the robots-txt audit and cost roughly 8% of the Lighthouse SEO score. Lighthouse now treats license the way it already treats Content-Signal: recognised as used in the wild, though not officially supported.

The caveat matters more than the fix. Google's robots.txt documentation (last updated 2026-10-23 UTC) still supports only user-agent, allow, disallow, and sitemap, and says other fields are not supported. So a License line is safe to publish, because Google's parser ignores lines it does not recognise rather than rejecting the file, but it is not a Google-honoured control. Treat it as a machine-readable licensing declaration for AI crawlers that read RSL, and keep your actual crawl policy in allow and disallow rules.

What to change: public/robots.txt. If you publish RSL terms, you can now do so without taking an audit penalty, and your per-bot decisions stay where they belong — as separate user-agent groups, since training, search, and user-triggered fetchers are independent choices.

# Licensing declaration: read by RSL-aware AI crawlers.
# Lighthouse >= 13.6.0 no longer flags this as an unknown directive.
# Google's parser ignores it; it is not a crawl control.
License: https://example.com/license.xml

# Training: opt out.
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# Search surfaces: opt in. Independent of the training decision above.
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Vercel adds per-bot AI traffic insights to Observability

Shipped 2026-10-27, live and additive (Vercel changelog). It reports requests per verified AI bot, splits crawler fetches for indexing or training from assistant retrievals triggered by a user action or search query, lists the pages most requested in Markdown, and flags pages where AI bot requests return errors. It lives at Observability to AI Traffic in the dashboard; querying the same metrics through the CLI requires Observability Plus.

Why this is worth an hour today: it is the first place most teams can check whether their robots.txt intent matches what is actually being served. OpenAI documents GPTBot, OAI-SearchBot, and ChatGPT-User as independent settings, and notes that robots.txt changes take around 24 hours to take effect on the search side. If your file refuses GPTBot while serving OAI-SearchBot, this view is where you confirm it, and where you catch a CDN or WAF rule silently overriding the policy you wrote.

No configuration is needed for the dashboard view. The pages-returning-errors list is the one to read first, because an AI bot collecting 404s or 5xx responses on canonical content is a loss that no ranking tool reports.

#!/usr/bin/env bash
# Observability > AI Traffic in the dashboard needs no setup.
# Querying the same metrics from the CLI requires Observability Plus.
set -euo pipefail

vercel metrics --help

# Cross-check that what robots.txt says is what the edge actually does.
# A 200 for a bot you disallowed means a CDN or WAF rule is overriding intent.
for UA in \
  "GPTBot/1.2" \
  "OAI-SearchBot/1.0" \
  "ClaudeBot/1.0" \
  "PerplexityBot/1.0"
do
  code=$(curl -sS -o /dev/null -w '%{http_code}' \
    -A "$UA" "https://example.com/")
  printf '%-22s %s\n' "$UA" "$code"
done

Next.js 16.5 canary reworks filesystem cache stamping: watch, do not ship

v16.5.0-canary.29, published 2026-10-27 23:46 (Next.js releases). Non-breaking today, because it is canary-only; the stable release remains v16.4.3 from 2026-10-23. The changes worth tracking: FileSystemCache revalidations and entries are now stamped with the monotonic clock (#100357), fully static PPR payloads are persisted to the filesystem cache (#100759), and the storage cache is persisted in Docker (#100790). canary.28 fixed draft-mode rendering with Cache Components (#100728) and a hanging HTML response after a 'use cache' error (#100673).

There is no symptom to fix today, which is exactly why it belongs on a watch list rather than in a pull request. ISR and 'use cache' entry lifetimes determine how fresh a crawler-visible page is, and moving expiry computation to a monotonic clock changes behaviour across process restarts. If you run Next.js in containers that restart often, that is the behaviour to measure before adopting 16.5.

Action: watch. Stay on stable 16.4.3, and write a revalidation assertion against your own cache semantics now, so that when 16.5 reaches stable you can tell a behaviour change from a coincidence.

AMP for WP stored XSS lands on search-facing pages with no fixed release

Advisory GHSA-cffj-cwcj-4vv7 / CVE-2026-97019, published 2026-10-28 by NVD and the GitHub Advisory Database. High severity, CVSS 3.1 base 7.2 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N), CWE-79. All versions up to and including 1.1.17 are affected, the advisory is marked unreviewed, and no fixed release is named.

The mechanism is specific and worth reading, because it explains why ordinary WordPress sanitisation does not catch it: a Subscriber-level account stores a malicious shortcode in its biographical info field; wp_filter_kses() strips HTML tags but not shortcode syntax; and AMP's content sanitizers run before do_shortcode() processes the archive description, so the generated markup is never sanitised after the shortcode expands. The script then executes for every visitor to the affected AMP page, which is a page built specifically to be served to search traffic.

What to change: with no patched version named, mitigate rather than upgrade. Confirm the installed version, restrict Subscriber-level registration or sanitise the biographical info field, and consider disabling the AMP archive description rendering path until a fix ships. Note the advisory's own inconsistency: it describes unauthenticated exploitation while the documented attack path requires a Subscriber account, so treat open registration as the real risk multiplier.

#!/usr/bin/env bash
# GHSA-cffj-cwcj-4vv7 / CVE-2026-97019 - AMP for WP <= 1.1.17 stored XSS.
# No fixed release is named, so verify exposure and mitigate.
set -euo pipefail

# 1. Installed version. Anything <= 1.1.17 is affected.
wp plugin get accelerated-mobile-pages --field=version

# 2. Is open registration on? That is the attack path.
wp option get users_can_register

# 3. Find shortcode syntax already stored in user bios.
wp db query "SELECT user_id, LEFT(meta_value, 120) AS bio
  FROM $(wp db prefix --allow-root 2>/dev/null || echo wp_)usermeta
  WHERE meta_key = 'description'
    AND meta_value LIKE '%[%'" || true

# 4. Interim mitigation: close registration until a patch ships.
# wp option update users_can_register 0

Ship today

1. Verify the home page to favicon crawl path end to end, and remove any robots.txt Disallow covering the favicon URL or the host serving it.
2. Exempt /robots.txt and /llms.txt from edge rate limiting, so Lighthouse 13.6.0 does not fail them on HTTP 429.
3. Add explicit robots-txt and llms-txt assertions to Lighthouse CI before 13.6.0 lands, so the new behaviour arrives as a named failure rather than a score drop.
4. Open Observability to AI Traffic and reconcile which AI bots are actually served against what robots.txt declares.
5. Audit the installed AMP for WP version and mitigate GHSA-cffj-cwcj-4vv7, since no fixed release exists.
6. Keep Next.js on stable 16.4.3 and add a revalidation assertion before evaluating the 16.5 canary filesystem-cache changes.