Daily SEO Note — October 7, 2026: Google Calls Fake Author Profiles Deception

1. SEO for Content Writers

Google put a name to a practice a lot of content operations quietly adopted this year. The helpful content guidance now states that fabricating creator profiles — AI-generated headshots, invented names, false credentials — is a form of deception, and that deception is a signal of a low-quality page. The page carries a last-updated stamp of 2026-10-05 UTC and the change surfaced across the industry on 6 October. Everything else today is smaller: two Search Console reporting changes, a parent/child wrinkle in the AI control, and a spam update that is still, officially, running.

Google now classifies invented author profiles as deception

The Creating helpful, reliable, people-first content page gained an explicit sentence: fabricating creator profiles, "such as by using AI-generated headshots, made-up names, or false credentials to make content appear as if it was written by human experts", is deception. The page then applies its existing standard to it — any form of deception "makes a page untrustworthy to both users and our automated quality systems, and is a signal of a low-quality page".

This is a reclassification, not a new rule. Fake bylines were already a bad idea; they are now named in the same document that defines the self-assessment questions Google tells site owners to ask. The scope is all content with a byline, and it bites hardest on sites that spun up author personas to satisfy E-E-A-T advice without hiring the people behind them. A stock-photo headshot attached to a real, named, accountable writer is not what this describes. A generated face attached to a name that does not exist is.

What to do differently: every brief that will carry a byline needs a real person attached before it is assigned, and that person needs a verifiable credential trail — an author page, prior work, a professional profile, something a reader can check. If a piece genuinely has no individual author, publish it under the organisation rather than inventing one.

What to stop doing: retire persona bylines. If your site has author profiles that were created to look like experts rather than to credit experts, the cheapest fix is to consolidate that work under a real editor or the brand, not to improve the fake profile's photograph.

Status: documentation change, live. Primary source: Creating helpful, reliable, people-first content, last updated 2026-10-05 UTC.

Your AI Overviews eligibility may be set on a property you do not own

Google updated the Search generative AI control help page on 6 October to document a notification: owners of a top-level domain property now see an alert on the control page when one of their child properties overrides the parent setting.

The control itself governs whether a site's content is eligible for AI Overviews, AI Mode, and generative features in Discover. It inherits down the property tree — a child property follows its closest configured parent until somebody configures the child directly. For an editorial team, the consequence is that a subdomain owner can opt a section out of AI answer surfaces without the main domain's knowledge, and until this change the domain owner had no signal that it happened.

What to do differently: before you attribute a drop in AI Overviews citations to your writing, ask whoever holds the domain-level Search Console property to check the generative AI control page for override notifications. This is a settings question, not a content question, and it is worth ruling out first. Note also that this control is separate from Google-Extended, which governs Gemini model training and does not affect Search inclusion.

Status: documentation change, live. Affects multi-property and subdomain publishers only.

Search Console performance filters accept several countries at once

Google confirmed on 6 October that the Search Console performance report now lets you select multiple countries in the country filter instead of one at a time, so a site operating in several markets can read their combined Google Search traffic in a single view. Device filtering was adjusted in the same change.

This is a small reporting change with a real effect on query research. Market-by-market exports made it easy to miss a query that is mid-sized in five countries and therefore invisible in each one. Grouping the markets that share a language — or share a localised article — changes which queries clear your threshold for a rewrite.

What to do differently: rebuild your query research view around the markets that share a page, not the markets that share a border. If one English article serves the UK, Ireland, Australia, and Canada, filter those four together and re-rank the queries before you plan the next update. Expect a handful of rewrite candidates you previously discarded.

Preferred source subscriber counts are arriving by email, not in Search Console

Site owners began receiving emails from the Search Console team on 6 October reporting how many people have selected their domain as a preferred source in Google Search, with the figure stated as of 2026-10-05. Google's message ties the feature to appearing "more often across features like Top Stories, AI Overviews, and AI Mode".

The number exists only in the email. There is no corresponding report in the Search Console interface, and the email links to a survey asking recipients whether the data should be added, how often they would want it, and which metrics would matter. Treat this as a measurement preview that Google is still deciding whether to build.

What to do differently: forward the email to whoever owns your newsletter and social calls-to-action, and save the figure with its date — if Google never ships the report, your own archive of these emails is the only trend line you will have. Preferred-source selection is a reader action, so the editorial lever is asking regular readers to choose you, not optimising a page.

Status: email rollout, observed. Google has not published documentation for this notification, so the subscriber figure is not yet a reportable metric with a stable definition.

Search profiles open in India and Canada

Google extended Search profiles to creators and publishers in India and Canada on 6 October, with Brazil named as next, announced by Robby Stein, VP of Product for Search. The profiles launched in the United States in June and had been US-only until now.

A Search profile is a customisable page that collects an author's or publisher's social accounts, sites, posts, and links in one place in Google Search. For the authorship question that leads today's section, it is a useful adjacency: it is a Google-hosted surface where a real author's identity and body of work can be asserted and checked.

What to do differently: if you publish with named authors in India or Canada, claim their profiles this week and point them at the author pages you already maintain. This is identity infrastructure, not a ranking tactic — do not expect a traffic change from it.

The September spam update is still open on Google's own dashboard

The Search Status Dashboard still lists the September 2026 spam update as active, with a start of 24 September 2026 09:15 PDT and no update posted since that start entry. Thirteen days in, Google has published no completion notice.

Community trackers reported a final phase of the rollout across 4–6 October and expected volatility to subside. That observation is unconfirmed: it does not appear on the dashboard or in any Google statement, and it is recorded here only so you can recognise the claim when you see it elsewhere.

What to do differently: nothing yet. Rankings observed during an open spam update are not a stable baseline, so hold off on rewriting pages in response to position changes until Google marks the rollout complete.

Apply to your next brief

• Assign a real, named author before the brief is written, and record the credential a reader could verify.
• Audit existing author profiles for generated headshots or invented names; consolidate that work under a real editor or the brand.
• Publish genuinely uncredited content under the organisation rather than creating a persona to carry it.
• Rule out a child-property override on the Search generative AI control before diagnosing an AI Overviews citation drop as a content problem.
• Group markets that share an article in the Search Console country filter, then re-rank queries for rewrite candidates.
• Archive each preferred-sources email with its date; the figure is not in Search Console and may never be.
• Treat positions seen while the September spam update is open as provisional, and postpone update decisions that depend on them.

2. SEO for Developers

Next.js 16.4 shipped on 6 October 2026 and changes the default caching posture for new applications: Cache Components are now recommended for every app and enabled by default by create-next-app. Existing projects are untouched until you opt in, which makes this non-breaking today and a migration you should schedule rather than absorb. Alongside it, Google's crawl-rate documentation added a Retry-After signal, Cloudflare promoted a command-injection rule from log to block, and Astro 7.3.6 fixed three bugs that silently removed pages from builds.

Next.js 16.4 makes Cache Components the recommended model and adds a static guarantee

Version 16.4.0 was published on 6 October 2026 at 18:35 UTC. Cache Components — the 'use cache' programming model — moves from a qualified recommendation to the recommended default, and will become the actual default in Next.js 17. New apps from create-next-app have it on. Existing apps need two flags.

Non-breaking for existing apps, because nothing changes until you set the flags. The symptom if you ignore it is deferred cost: Next.js 17 will flip the default, and the implicit caching behaviour your App Router pages rely on today is what the new model replaces. The 16.4 release also ships React 19.3, a Turbopack disk cache 20–25% smaller, and export mangling that shrinks production bundles.

The genuinely SEO-relevant addition is ensureStatic, a route segment config that fails the build when dynamic content enters a route. Until now a single request-time component could quietly turn a prerendered marketing page or article into a server-rendered one, with no build-time signal. Set it on the root layout and a stray dynamic component becomes a build error instead of a crawl-time surprise.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  // Both flags together constitute the Cache Components model.
  cacheComponents: true,
  partialPrefetching: true,
};

export default nextConfig;

// Fail the build if any page under this layout renders at request time.
// 'navigation' is the strictest level; 'prefetch' and 'shell' are narrower.
export const ensureStatic = 'navigation';

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

Primary source: Next.js 16.4 release post, 6 October 2026, and the cacheComponents config reference.

Google's crawl-rate doc now documents Retry-After

Reduce the Googlebot crawl rate carries a last-updated date of 2026-10-06 UTC. The emergency guidance is unchanged in substance — return 500, 503, or 429 instead of 200 to cut crawl rate across the whole hostname — but it now states that with a 503 or 429 you can also include a Retry-After header, as defined in RFC 9110, to tell Google's crawlers when to retry.

Non-breaking, and worth wiring up before you need it. The header takes either a delay in seconds or an absolute UTC date. The documentation's warning is the part to respect: do not serve these codes for longer than one to two days, or URLs start dropping out of the index. The failure mode is an incident that outlives its maintenance window and takes pages with it.

Put the header in whatever serves your maintenance or rate-limit response, and make the duration a variable you can shorten. If you already return 429 from an edge rate limiter, adding Retry-After is a one-line change that converts a blunt refusal into a scheduling hint.

# Serve a crawl-safe maintenance response.
# Retry-After accepts a delay in seconds or an HTTP-date (RFC 9110).
location / {
    if (-f /etc/nginx/maintenance.flag) {
        add_header Retry-After 3600 always;
        return 503;
    }
}

# Edge rate limiting: pair 429 with the same signal.
limit_req_status 429;
add_header Retry-After 120 always;

Primary source: Reduce the Googlebot crawl rate, last updated 2026-10-06 UTC. Capacity planning context in Managing crawl budget for large sites.

Cloudflare moved a command-injection rule from log to block on 6 October

The WAF release of 2026-10-06 merged the beta rule "Command Injection - Generic 8 - uri - Beta" into the baseline rule of the same name and changed its action from Log to Block. A new rule for CVE-2026-94127, an unauthenticated heap overflow in F5 BIG-IP, was added with a Block action.

This is the item most likely to cause a crawl problem you did not cause. A rule that was recording matches is now refusing them, and the match is on the URI. Any legitimate URL pattern that resembled command injection was previously invisible in your logs and is now a 403 — to users and to Googlebot alike. The symptom is a sudden cluster of 403s in Search Console's crawl stats with no deploy to explain it.

Check the Firewall Events log for matches on that rule over the past weeks before this release, since the Log action means the evidence is already sitting there. If your URLs trip it, add a skip rule scoped to those paths rather than disabling the rule. The third change in this release — the Next.js cache poisoning rule for CVE-2026-94543 — is metadata only, with detection explicitly unchanged, so it needs no action.

# Confirm Googlebot is not being blocked at the edge.
# Expect 200; a 403 means a WAF rule is matching your URI pattern.
curl -s -o /dev/null -w '%{http_code}\n' \
  -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \
  'https://example.com/your/affected/path?query=value'

# Always confirm a real crawler by reverse DNS, never by user agent alone.
host 66.249.66.1 | grep -E 'googlebot|google\.com'

Astro 7.3.6 fixes three bugs that removed pages from builds

Astro 7.3.6 was published on 6 October 2026 at 12:45 UTC. Three of its patches are indexing problems rather than developer-experience problems, which makes this a patch release worth taking promptly.

First, the glob() content collection loader skipped content files whose paths contain a # or a ? character. Those entries never became pages, so they were absent from the build and from any sitemap generated from it — a silent omission with no error. Second, the composable i18n() handler from astro/fetch and astro/hono returned an empty 404 for paths without a locale prefix instead of rendering the custom 404 page, which is the shape of a soft 404. Third, routes added with injectRoute() returned 404 when i18n.routing.prefixDefaultLocale was true and the route path had no locale prefix.

Non-breaking upgrade, and the first bug is the one to act on: if any of your content filenames or slugs contain # or ?, pages are missing right now and you would not see it in a build log. Upgrade, then diff your sitemap entry count against your content collection count.

npm install [email protected]

# Then verify nothing is missing: compare sitemap URLs to collection entries.
npx astro build
grep -c '<loc>' dist/sitemap-0.xml
find src/content -type f \( -name '*.md' -o -name '*.mdx' \) | wc -l

Primary source: Astro package changelog, 7.3.6, published 6 October 2026.

The generative AI control is a property setting, not a robots directive

The parent/child override notification documented on 6 October in the Search generative AI control help page is worth reading on the engineering side too, because this control lives nowhere in your repository. It is configured per Search Console property and inherits down the property tree; a child property keeps following its closest configured parent until somebody sets the child explicitly.

That means no amount of auditing robots.txt, meta tags, or response headers will tell you a site's AI Overviews and AI Mode eligibility. Keep it separate in your head from the three controls that do live in your code or DNS: Google-Extended in robots.txt governs Gemini training and grounding and has no effect on Search inclusion, nosnippet and max-snippet govern snippet text, and the AI features documentation covers the rest.

Add the Search Console setting to whatever runbook covers your indexing regressions, with a note on who owns the domain-level property. The failure case is an engineer spending a day on robots.txt for an opt-out somebody set in a web interface.

Ship today

1. Add Retry-After to your 503 and 429 responses, with the delay as a configurable value, and cap any maintenance window that serves them at one to two days.
2. Upgrade Astro to 7.3.6 if you run content collections, then compare your sitemap URL count against your content file count to catch pages the glob() bug dropped.
3. Review Cloudflare Firewall Events for historical Log matches on Command Injection - Generic 8 - uri, and add a scoped skip rule if legitimate URLs match now that it blocks.
4. Set ensureStatic = 'navigation' on the layouts covering your articles and marketing pages, so a dynamic component fails the build instead of degrading them at request time.
5. Schedule the Cache Components migration for an existing app rather than doing it today; Next.js 17 will make it the default, and next upgrade --agent exists to help.
6. Record the domain-level Search Console property owner in your indexing runbook, next to the generative AI control setting.

What did not change

No new release of web-vitals: 6.2.3 from 5 October remains the latest, and yesterday's LCP attribution and INP memory-leak fixes are still the current ones. Lighthouse's latest tagged release is still 13.5.0 — the 13.5.0-dev builds appearing daily on npm are nightly dev snapshots, not releases. Schema.org is still on version 30.1 from 16 September 2026, with no vocabulary change today. No new security advisory landed against an SEO package, sitemap generator, or crawler dependency in the window.