Daily SEO Note — September 20, 2026: Lighthouse Starts Scoring Agent Discovery

Audit window: 2026-09-19 06:00 UTC to 2026-09-20 06:00 UTC. The window itself was quiet — no primary source published a new announcement inside it, and the Search Status Dashboard reported Crawling, Indexing, Ranking and Serving all available with no incidents as of 2026-09-19 23:03 PDT. The verified changes below carry their own dates, which cluster on September 16 and 18; each one is still current and none has been covered in this series before.

SEO for Content Writers

The consequential editorial change is that Google began testing a layer between the Discover feed and your article. A “Dive deeper” button now opens a machine-generated topic overview instead of the publisher's page. Everything else today is distribution plumbing — a documented Search profile badge, and EEA result units that now cover local business queries.

Google Discover is testing a “Dive deeper” button that opens an AI topic overview

On September 18, 2026, Google started experimenting with a “Dive deeper” control inside Discover. Tapping it does not send the reader to the article that prompted it. It opens a short generated overview of the topic, with links out to related stories, community reaction, and original reporting. Google's VP of Product for Search announced the experiment publicly the same day and said it starts with video content, with multiple designs planned in the weeks ahead.

Who it affects: news and topical publishers first, and video-led coverage most immediately. This is a test, not a rollout, so there is nothing to react to structurally yet. What matters is the shape of the thing: the overview cites original reporting as a distinct category of link. Being the identifiable origin of a fact is the lever that survives the summary layer.

What to do differently in the next article: put something in the first 150 words that an overview cannot synthesize from the rest of the feed — a number you generated, a named source you spoke to, a test you ran, a document you obtained. Attribute it to yourself explicitly in the sentence, not only in a byline, so the attribution travels when the sentence is quoted.

What to stop doing: stop opening with a paragraph that restates the topic before delivering anything. That paragraph is exactly what a topic overview replaces. Discover eligibility itself is unchanged — content qualifies if it is indexed and complies with the content policies, and no special markup is required, per the Google Discover documentation (last updated March 9, 2026). Status: limited experiment, announced September 18, 2026.

Search profiles now have documented badge assets, and following one feeds Discover

On September 16, 2026, Google published Add a Search profile badge to your website. A Search profile pulls a publisher's or creator's content from across the web and social platforms — Instagram, TikTok, YouTube, X, Facebook and the site itself — into one destination at the profile.google.com/@handle pattern. The new page supplies the official badge assets, the HTML to embed them, and the brand rules that govern placement.

The part that matters editorially is buried in the mechanics: when a reader follows your Search profile, the documentation states it makes the content linked on that profile more likely to appear for that audience in Google Discover. That is an audience-owned distribution path that does not route through ranking. It behaves more like a subscribe button than an SEO feature.

What to do differently: claim the Search profile, then place the badge where a reader who already finished something of yours will see it — the end of articles, author pages, and the footer. Treat it as a conversion surface with a real call to action, not a logo you park in a sidebar. If you also run the Preferred Sources badge, the documentation says to use the higher-emphasis Search profile button with its label so the two do not compete for the same glance.

Status: live documentation as of September 16, 2026. Badge placement has minimum touch targets (48×48 dp on Android, 44×44 px on iOS and web) and the Super G icon may not be recolored or distorted.

EEA aggregator and supplier units now cover local business queries

Google updated both the aggregator unit and supplier unit documentation on September 18, 2026. Both pages now list local businesses alongside hotels, flights, long-distance trains or buses, and products as supported query types. The change was logged the same day in the Search documentation changelog.

Who it affects: one vertical, one region. This is European Economic Area only. If you publish local service content, directory pages, or comparison content aimed at EEA readers, local queries there can now surface an aggregator side showing approved vertical search services and a supplier side showing the businesses themselves.

What to do differently: for EEA local pages, make the operational facts plainly crawlable in HTML — business name, address, service area, hours, the services actually offered. The supplier unit documentation is explicit that you do not need to provide data beyond what is accessible through web crawling. That makes this an editorial completeness problem rather than a feed problem. Status: live in the EEA, documentation updated September 18, 2026.

No ranking update is running, and the dashboard says so

The Search Status Dashboard showed no active ranking update and no incidents across Crawling, Indexing, Ranking and Serving through 2026-09-19 23:03 PDT. The most recent confirmed ranking update on record remains the August 2026 spam update. If you see weekend movement in a third-party tool, there is no announced Google event to attribute it to — do not rewrite a page this week on the theory that an unnamed update hit it.

Your llms.txt is now an editorial artifact, because a Google tool grades it

Lighthouse 13.5.0 shipped on September 18, 2026 with audits grouped under a new agent discovery heading, covering llms.txt and the Agentic Resource Discovery proposal. The engineering detail is in Section 2. The editorial consequence is simpler: llms.txt is a curated, hand-written markdown index of the pages that best represent your site, and someone now has to decide which pages those are. That is an editor's decision, not a build step.

The llms.txt specification reached v2 and was last modified August 10, 2026. It describes a markdown file at the site root listing your key content with short descriptions. Write those descriptions the way you would write a section intro — a clause that says what the page settles, not a keyword string.

What to do differently: own the llms.txt entry list in the same review where you decide internal linking. When you consolidate or prune an article, remove it there too. A file that points at pages you deprecated is worse than no file, because it is a machine-readable claim about what your site is for.

Unconfirmed: rank trackers and scrapers report being blocked since mid-September

Community reports since roughly September 13, 2026 describe Google blocking search scrapers and third-party tracking tools more aggressively, surfaced through search forum discussion on September 18. This is unconfirmed. Google has published nothing about it, there is no dashboard entry, and no primary source states it. It is listed here only so that you recognise the symptom.

What to do differently: if a rank-tracking tool shows a sudden gap or a cliff this week, treat it as a possible instrumentation failure before you treat it as a ranking loss. Confirm against Search Console impressions and clicks, which are first-party, before you commission a single rewrite off third-party data.

Apply to your next brief

• Front-load one original, self-attributed fact in the first 150 words — a number, a named source, a test result, a document.
• Delete the scene-setting opening paragraph. A topic overview already does that job, and better.
• Add a Search profile badge placement to the brief template: end of article, author page, footer.
• For EEA local content, list name, address, service area, hours and actual services as crawlable HTML text.
• Assign an owner for the llms.txt entry list, and update it whenever an article is pruned or consolidated.
• Verify any suspected ranking drop against Search Console before acting on third-party tracker data.
• Do not attribute weekend volatility to a core update. None is running.

SEO for Developers

The consequential engineering change is that agent discovery became a scored Lighthouse category. Two files you may not have on disk — /llms.txt and /.well-known/ard.json — are now things a Google-maintained auditor looks for, and that audit reaches PageSpeed Insights within roughly two weeks of the release. Schema.org also shipped a vocabulary release, and OpenAI moved its crawler documentation to a new host.

Lighthouse 13.5.0 adds an Agentic Resource Discovery audit and groups it with llms.txt

Lighthouse v13.5.0 was published on September 18, 2026 at 16:18 UTC. It adds an audit for the ard-schema, refines the WebMCP audits including form-coverage pass/fail logic and tool-registration warnings, adds response-header capture to the fetcher, and consolidates the llms.txt and ARD audits under a single agent discovery category. The release notes state it is expected to ship in the DevTools of Chrome 156 and to reach PageSpeed Insights within two weeks.

Non-breaking. Nothing you have already built stops working. The symptom if ignored is narrower than it sounds: a new audit group appears in your Lighthouse and PSI reports, and your site registers as absent from it. If you run Lighthouse CI with category thresholds, a new set of audits entering the report is the kind of thing that moves a score without any change on your side, so check your assertion config before the Chrome 156 DevTools rollout rather than after.

The file to add is /.well-known/ard.json. The ARD specification is at v0.91 and carries Proposal status, dated August 26, 2026 — it is a draft, developed in a working group that includes Google and Microsoft, not a ratified standard. Treat adopting it as a cheap bet, not a requirement. The manifest is a JSON document with an entries array; each entry requires identifier (a domain-anchored URN), displayName, type (an IANA media type), and exactly one of url or data.

{
  "entries": [
    {
      "identifier": "urn:air:oday.dev:docs:seo-notes",
      "displayName": "Daily SEO Notes",
      "type": "text/markdown",
      "url": "https://oday.dev/llms.txt"
    }
  ]
}

Serve it as application/json. If you are on Next.js, a file at public/.well-known/ard.json is served verbatim with no route handler needed; on Vercel no extra configuration is required for the dot-prefixed directory.

llms.txt reached v2, and llms-full.txt is not part of the specification

The llms.txt specification is at v2, published originally September 3, 2024 and last modified August 10, 2026, rewritten around two years of adoption data. It defines a markdown file at /llms.txt, plus the convention of serving markdown versions of pages at a .md extension. It does not define llms-full.txt. If your generator emits that file because a blog post said to, you are shipping a convention the specification does not describe.

Non-breaking, and the cost of the mistake is only wasted bytes and a misleading signal. The fix is to make /llms.txt a real curated index rather than a dump of every URL. Note the specification is a proposal, and the site itself points out that Lighthouse now audits for it — which is what connects this item to the release above.

# Oday

> Fullstack development, SEO engineering and AI integration notes.

## Docs

- [Daily SEO Notes](https://oday.dev/blog): Dated audits of ranking, crawling and AI-surface changes.
- [Dev Release Radar](https://oday.dev/blog): Daily release and CVE tracking across the web stack.

## Optional

- [About](https://oday.dev/about): Author credentials and contact.

OpenAI moved its crawler documentation, and the fleet is now four bots

platform.openai.com/docs/bots now returns 301 Moved Permanently to developers.openai.com/api/docs/bots. Non-breaking for your site, but breaking for any documentation link, monitor, or runbook that pins the old host — update the reference rather than relying on the redirect. The documented fleet is GPTBot (training, v1.4), OAI-SearchBot (surfaces sites in ChatGPT search, v1.4), ChatGPT-User (user-triggered fetches from ChatGPT and GPT Actions, v1.0), and OAI-AdsBot, which validates landing pages for ChatGPT ads and is documented as not feeding model training.

Keep these as three separate decisions, because they buy different things. Blocking GPTBot opts you out of training. Blocking OAI-SearchBot removes you from ChatGPT's search answers, which is a traffic decision, not a rights decision. ChatGPT-User fires because a human asked, and the documentation notes robots.txt rules may not apply to those requests since they originate from a user action. The documentation also notes robots.txt changes take approximately 24 hours to be reflected for OAI-SearchBot, so do not judge a change by the next morning's logs.

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

User-agent: CCBot
Disallow: /

# Search and answer surfaces: opt in — this is distribution.
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://oday.dev/sitemap.xml

Verify the result at the edge, not in the repository. A CDN bot rule can return 403 to a crawler you just allowed in robots.txt, and robots.txt will still look correct in source control. Per-bot IP ranges are published at openai.com/gptbot.json, openai.com/searchbot.json and openai.com/chatgpt-user.json for reverse-verification in log analysis.

Schema.org 30.1 adds Digital Product Passport and eCommerce vocabulary

Schema.org version 30.1 was released on 2026-09-16. It adds a DigitalProductPassport class for EU Digital Product Passport discovery, with EnvironmentalProductDeclaration and DeclarationOfConformity as Certification subtypes, and new properties including hasDigitalProductPassport, authorizedRepresentative, importer, recycledContentPercentage and substanceOfConcern. On the commerce side it adds consumerNotice, isOftenBoughtWith, specification, itemPopularity, valueGroup and minimumOrderValue, plus MaximumRetailPrice in PriceTypeEnumeration. MedicalSpecialty gains Ophthalmology and Audiology.

Additive and non-breaking — no existing term was removed. The trap is assuming vocabulary equals eligibility. Schema.org publishing a term does not create a Google rich result, and Google's structured data feature guides are the only authority on what earns an enhancement. Adding these properties will not produce a new SERP feature today. Add them where they describe something true about the product, for the non-Google consumers that read the graph, and validate with the Rich Results Test for Google eligibility separately.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Product",
  "recycledContentPercentage": 42,
  "hasDigitalProductPassport": {
    "@type": "DigitalProductPassport",
    "url": "https://example.com/dpp/sku-1234"
  },
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}
</script>

The EEA aggregator unit needs a feed; the supplier unit needs nothing

The aggregator unit and supplier unit documentation were both updated on September 18, 2026 to include local business queries. The integration asymmetry is the engineering point. The aggregator unit requires approval as a Vertical Search Service, content matching the query type, and data supplied through a real-time API or a direct feed. The supplier unit requires none of that — the documentation states you do not need to provide data beyond what is accessible through web crawling.

So if you operate a directory or comparison service targeting the EEA, this is a feed-integration project with an approval gate in front of it. If you operate the business itself, the entire engineering task is making sure the pages render their operational facts in server-delivered HTML. Check that your local pages are not gating name, address, hours or service lists behind client-side fetches that a crawler may never execute. Status: live in the EEA.

No new advisories for the SEO package supply chain

A sweep of the GitHub Advisory Database for next-sitemap, next-seo, sitemap, @nuxtjs/sitemap and @astrojs/sitemap returned no new advisories in the audit window. The most recent sitemap-adjacent entries remain the Ultimate Sitemap Parser advisories from June 2026 and the Crawlee SSRF advisory from May 2026, none of which affect the JavaScript SEO packages above. No action.

Ship today

1. Add /llms.txt as a curated index, and delete any generated llms-full.txt — the specification does not define it.
2. Add /.well-known/ard.json with a minimal valid entries array, served as application/json.
3. Review your Lighthouse CI assertion config before Chrome 156 lands, so the new agent discovery audits do not move a threshold you did not intend to move.
4. Update any monitor, runbook or doc link pointing at platform.openai.com/docs/bots to developers.openai.com/api/docs/bots.
5. Split your robots.txt AI rules into training, search and user-triggered, then verify at the edge that the CDN is not overriding the intent.
6. If you serve EEA local pages, confirm name, address, hours and services are in server-rendered HTML, not client-fetched.