# Pulse · August 5, 2026

> Cloudflare's AI-training toggle may already block Googlebot, Google tests a sign-in wall on deep results, and Assistant's mobile shutdown gets a firm date.

Canonical: https://brandonlazovic.dev/pulse/2026-08-05/  
Author: Brandon Lazovic  
Published: 2026-08-05

## Delivery Hero migrates semantic search to Amazon OpenSearch Service, cutting p95 latency by half with radial search

Status: Confirmed  |  Topics: platform-ecommerce, ai-data-stack

Delivery Hero moved its semantic search stack off a self-managed Elasticsearch 7.x cluster and a legacy Lucene service onto Amazon OpenSearch Service 3.x, AWS detailed on August 4, 2026. The migration adopted radial search, which returns every result above a minimum similarity score rather than a fixed nearest-neighbor count, and cut p95 query latency roughly in half, from over 200ms to a stable 100ms baseline.

In plain terms: Instead of always returning a fixed number of 'closest' search results, this method returns anything similar enough, so a very specific search can return few precise matches and a broad one can return many, rather than forcing the same count every time.

Why it matters: A documented, metric-backed migration path for threshold-based semantic retrieval gives e-commerce search teams evaluating similar re-platforming work a concrete latency benchmark to test against.

Our take: Radial search's real advantage is the retrieval logic: a similarity floor scales the result set to the query's specificity instead of forcing every query through the same top-K cutoff. Any e-commerce search or on-site AI-search rebuild considering vector retrieval should test a minimum-score threshold against its own top-K baseline before assuming a fixed-count approach is the right default.

- [AWS Big Data Blog: Transforming search at Delivery Hero, a migration journey to OpenSearch Service with radial search](https://aws.amazon.com/blogs/big-data/transforming-search-at-delivery-hero-a-migration-journey-to-opensearch-service-with-radial-search/)

## Sites blocking AI training on Cloudflare report Googlebot 403 errors weeks before the rule takes effect

Status: Observed  |  Topics: crawling-indexing-rendering

A Reddit thread reported that enabling Cloudflare's 'AI Training: Block' setting is already returning HTTP 403 errors to Googlebot and Bingbot on sitemap requests, weeks ahead of Cloudflare's own September 15, 2026 effective date, Search Engine Journal reported August 4. Cloudflare's July 1 policy classifies Googlebot, Applebot, and Bingbot as mixed-purpose crawlers blocked under whichever rule, Search or Training, is most restrictive. Google's John Mueller has asked the reporting user to follow up directly to investigate.

In plain terms: Cloudflare lets sites block AI companies from scraping content to train models, but Google's own search crawler technically fits the same 'trains on content too' bot category. Blocking one can accidentally block the other, and some site owners say that is already happening before the rule is even scheduled to start.

Why it matters: If a policy scheduled for six weeks out is already firing, sites that toggled AI-training blocks for unrelated reasons could be losing Google indexing coverage right now with no error surfacing in Search Console.

Our take: I've written about a different way a security layer can quietly cost you Google's index: a bot-challenge screen that returns 200 instead of an error and gets indexed as your canonical. The mechanism here is a 403 instead of a mis-issued 200, but the failure class matches: a classification rule built for one purpose catches Googlebot as collateral, and nothing in Search Console names the cause, so check access logs for 403s on Googlebot's user agent before assuming an AI-training block is behaving as intended.

- [Search Engine Journal: Report that Cloudflare AI bot blocking prevents Googlebot from indexing sites](https://www.searchenginejournal.com/report-that-cloudflare-ai-bot-blocking-prevents-googlebot-from-indexing-sites/584673/)
- [The Cloudflare Blog: Your site, your rules, new AI traffic options for all customers](https://blog.cloudflare.com/content-independence-day-ai-options/)

## Google tests requiring sign-in to view search results beyond the first few pages

Status: Observed  |  Topics: organic-search-core, crawling-indexing-rendering

A searcher spotted, and posted on X, a Google Search prompt reading 'Sign in to verify you're a human and see more results' after paging deep into results, Search Engine Land reported August 4, 2026. Google typically serves a CAPTCHA to verify suspected bot traffic at that point. This test asks for an actual Google account sign-in instead. Google has not commented, and the report frames it as a limited test with no confirmation of a wider rollout.

In plain terms: Right now, if Google suspects a bot for clicking through many pages of results, it shows a simple 'prove you're human' puzzle. This test replaces that puzzle with a requirement to log into a real Google account, a much bigger ask that would tie that activity to an identity.

Why it matters: A sign-in requirement instead of a CAPTCHA would materially raise the cost of automated rank-tracking and SERP-scraping tools that page deep into results, the same tools much of the SEO industry's own measurement depends on.

Our take: If this graduates past a limited test, the practical casualty is free-tier rank trackers and scraping-based SERP tools that lean on anonymous, high-volume querying, not the practitioner running a handful of manual checks a day. Whether Google scopes the trigger to query volume or to page depth decides whether ordinary power users get caught in the same net as scrapers.

- [Search Engine Land: Google Search testing forcing searchers to sign in to get more search results](https://searchengineland.com/google-search-testing-forcing-searchers-to-sign-in-to-get-more-search-results-484223)

## Google confirms Google Assistant leaves mobile devices on September 4, replaced by Gemini

Status: Confirmed  |  Topics: chatgpt-assistants, llm-models-agents

Google emailed users this week confirming Google Assistant is being discontinued on mobile devices starting September 4, 2026, a rollout Google says may take a few weeks to reach everyone, 9to5Google and Search Engine Roundtable reported August 4 and 5. Gemini becomes the default assistant on Android phones, tablets, Wear OS watches, compatible headphones, and Android Auto projected from a paired phone. Cars with Google built-in keep Google Assistant beyond that date.

In plain terms: The voice assistant that has answered 'Hey Google' questions on phones for over a decade is being switched off on September 4 and replaced by Gemini, so the same voice command will trigger a different assistant with different capabilities.

Why it matters: A hard cutover date on a decade-old voice assistant with a huge installed base is a forcing function for any brand or content strategy still tuned to 'OK Google' query patterns rather than Gemini's conversational style.

Our take: The consequential migration risk sits in the query and command patterns built around Assistant's narrower, more literal parsing. Gemini's conversational range means the same spoken query can resolve differently, so any voice-search or in-car integration tuned to Assistant's response format is worth re-testing against Gemini before September 4, not after.

- [9to5Google: Google Assistant shutting down on Android and Wear OS in September](https://9to5google.com/2026/08/04/google-assistant-september-2026-shutdown/)
- [Search Engine Roundtable: Google Assistant Shutting Down On Mobile Devices On September 4](https://www.seroundtable.com/google-assistant-shutting-down-41822.html)

## Simon Willison's LLM tool adds server-side tools and reasoning traces; the Anthropic plugin brings Claude's own MCP connector along

Status: Confirmed  |  Topics: llm-models-agents

Simon Willison released LLM 0.32 on August 4, 2026, adding support for OpenAI's Responses API, provider-hosted server-side tools (OpenAI's Code Interpreter and web search; Anthropic's web search, web fetch, code execution, and MCP connector), visible reasoning traces on stderr, and a content-addressable logging store. The companion llm-anthropic 0.26 plugin adds Claude Opus 5, Sonnet 5, and Fable 5 support plus access to those same Anthropic server-side tools through the -T flag.

In plain terms: Instead of your own program fetching a web page or running code and handing the result to the AI model, the model's own provider now does that work behind the scenes. This update lets Willison's popular command-line AI tool use that shortcut for both OpenAI and Anthropic's models.

Why it matters: Server-side tools mean the model provider, not your own code, executes the web fetch or MCP call, which changes both the latency profile and the audit trail practitioners scripting LLM pipelines need to account for.

Our take: I argued this week that an MCP server is a credential-scoped dependency, not a security boundary, because the protocol standardizes the wire format rather than the tool's trustworthiness. llm-anthropic's new server-side MCP connector moves that call onto Anthropic's own infrastructure instead of your machine, but the same audit questions still apply: what can that server's credential do, and would you recognize its tool names firing mid-session.

- [Simon Willison: New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging](https://simonwillison.net/2026/Aug/4/new-release-of-llm/#atom-everything)
- [Simon Willison: llm-anthropic 0.26](https://simonwillison.net/2026/Aug/4/llm-anthropic/#atom-everything)