Search and AI Changes: August 31–September 6, 2026

The default and import change

In its August 27 announcement, Microsoft says AI Max is available to all advertisers and enabled by default for new Search campaigns, with an option to turn it off. Google imports can carry AI Max settings across; scheduled imports can inherit them again on later syncs. Existing automatically generated responsive-search-ad assets do not, by themselves, enroll a campaign in the full suite.

The bundle covers search term matching, text customization and final URL expansion. Those are paid-campaign features, not instructions for improving organic Bing rankings. We checked Microsoft’s announcement on September 5; we have not tested AI Max in an advertising account.

Save the starting state before deciding

Our recommendation is a short state record, not a blanket instruction to enable or disable automation. Save the campaign’s current settings, the person approving the test, the intended landing pages and the conversion goal. A screenshot is useful evidence, but a written decision explains why the settings were chosen.

A synthetic example: a team approves a campaign after inspecting its settings, then another colleague changes the source campaign before the next scheduled import. The useful question at the next review is which state actually served during the measured period. An approval from before the sync is not evidence of the later state.

Inspect the landing pages before testing reach

Choose a small set of destinations to examine manually. Does each page describe an offer the business can deliver? Are prices and availability current? Can a visitor distinguish a product page from an expired promotion or an informational article?

Record acceptable and unacceptable destination types, then compare the pages that receive campaign traffic with that record. This is a proposed review procedure; it does not imply every unwanted route can be prevented by a particular control. Check the options available in your account before promising an exclusion.

Microsoft documents an “AI optimized” reporting label, an asset report and a search-term landing-page report. Use the reports to inspect what happened, while keeping your own approval record for what was intended.

Make the comparison readable

Pick the primary outcome before looking at the results: for example, qualified enquiries under one consistent qualification rule. Save spend, conversion definition, date window and any concurrent offer change. A higher conversion count is difficult to interpret if the team also added a lower-value conversion action during the test.

Prefer a controlled experiment when your account supports an appropriate design. If you can only compare before and after, label it observational. Note changed budgets, promotions, seasonality and tracking rather than assigning every difference to AI Max. Do not stop a comparison solely because the first few days look unusually good or bad; define its review window and spending boundary in advance.

For larger reporting workflows, our measurement comparison guide explains why metrics with different definitions should not be combined. For assistant-generated campaign summaries, use the separate Microsoft Advertising MCP report checks.

Download the settings record

Download the AI Max settings audit CSV. Use one row per campaign review or import event. Fill in the three feature states, source and destination notes, sync time, approved landing pages, outcome definition, review date and owner decision. Replace all EXAMPLE-REMOVE rows; they describe fictional scenarios, not our account results.

Keep campaign identifiers and confidential exports in your own restricted workspace; the template needs only an alias and a private evidence reference. If a sync produces a state the owner did not approve, pause the rollout decision and resolve the source of that state before changing several controls at once.

What this does not establish

This article does not establish an expected uplift for your business. Its contribution is a reproducible settings and evaluation record, not an independent product review. We will update the instructions when Microsoft changes default or import behavior, or when account-level testing supplies evidence that can be disclosed and reproduced.

Counter-GEO-Bench tests information distortion

Counter-GEO-Bench, by Bing Zheng, Zongyao Zhao, and Wenming Yang, pairs 247 human-verified queries with information-preserving and information-distorting rewrites. Across three open-weight victim models, the authors report that their C-GEO Guard baseline reduces attack success by 47.6% relative. The tested off-the-shelf defenses achieve at most a 5.7% relative reduction.

The arXiv record states acceptance to EMNLP 2026’s main conference. Its limitations section still matters: the work does not test end-to-end commercial search products or proprietary APIs, and the evaluation uses a limited English query set and a single attacker-controlled document. Adaptive attacks remain untested.

These findings support a specific concern about fluent misinformation in retrieved material. They do not measure the rate of misinformation in public ChatGPT or Google answers.

GEO Defender tests manipulation beyond false facts

When Optimization Becomes Manipulation studies attacks that can preserve factual content while changing which sources a generative search system selects or cites. The proposed GEO Defender combines a reranking defense with a generation-stage defense.

The authors report attack success falling from 50.32% to 6.20% across their evaluation, with 94.12% benign-evidence preservation. Their experiments cover five language models and seven attack strategies. The paper’s current version is a research report, not evidence that a commercial engine has deployed the defense.

The percentage-point difference between 50.32% and 6.20% is 44.12. It is not directly comparable with Counter-GEO-Bench’s relative reduction: the papers define different threats, systems, and evaluation conditions.

A truthful sentence can still support an unfair answer

Imagine a fictional comparison of two delivery services. Both sources accurately state their own opening hours, but the final answer uses only one provider’s claims and ignores a more relevant limitation in the other source. Every quoted sentence might be true while the comparison remains unbalanced.

Now imagine an answer that repeats an invented delivery guarantee from a retrieved page. That is a factual-support failure. Correcting source diversity alone would not necessarily remove the false guarantee.

These examples are SearchEngineAnswer’s illustrations, not cases drawn from either benchmark. They show why “the answer has citations” is an incomplete quality test. A citation can be attached to an unsupported statement, and a supported statement can come from an unrepresentative selection.

Use two review tracks

Run the tracks independently. If reviewers cannot inspect the retrieved candidate set, mark source-selection quality as only partially observable. The public answer alone cannot reveal everything the system had available.

Download the review sheet

Download the GEO defense review sheet (CSV). Its synthetic rows are labeled EXAMPLE-REMOVE. It records claim support, source-set visibility, omitted evidence, and the treatment of legitimate material separately. It contains no attack payloads or private benchmark data.

Before evaluating a product, agree what counts as a failed claim and what counts as an unjustified source preference. Have a second reviewer check disputed rows against the same evidence. Keep “unknown” available as a result; forcing a verdict without the retrieved context manufactures certainty.

For a controlled internal system, compare the same questions and source collection with the defense on and off. Freeze document versions and retain the unmodified control. Report failed examples as well as aggregate results, and do not silently remove questions where the defense produces no useful answer.

What publishers should take from the papers

Our earlier Citation Wars analysis asks whether competitive optimization can damage content quality. These new papers address a different question: how an answer system might defend its evidence pipeline. Neither licenses publishers to manipulate source selection or invent claims.

For editorial work, retain qualifications, link supporting evidence, and make comparisons inspectable. Pair a citation count with the actual use of a source in the answer. More citations alone cannot establish accuracy, balanced coverage, or useful referral traffic.

We reviewed the September 2 versions on September 4, 2026. We have not replicated either benchmark. The comparison framework and worked review sheet are our contribution; the reported experimental results belong to the respective authors.

What changes in February 2027

Google’s begin-to-render notice moves the counting point from the start of an ad download to successful loading and the start of rendering. The affected inventory is banner display on desktop web, mobile web, and connected TV. Native, app, and video inventory already uses or complies with begin-to-render measurement.

Google says the transition is automatic and impressions may decrease because counting happens later. It recommends Ad Manager comparisons using Ad server impressions and Ad server begin to render impressions, with a historical start date after August 12, 2026. Additional aggregate BTR metrics are described as forthcoming, not all available today.

This is an announced future change. SearchEngineAnswer has not measured its effect on publisher revenue.

A higher RPM can come from a smaller denominator

Here is an illustrative example, not a forecast. A publisher earns $100 from 50,000 counted ad impressions. Impression RPM is $100 divided by 50,000, multiplied by 1,000: $2.00.

If the same $100 is divided by 40,000 impressions under a different counting rule, impression RPM becomes $2.50. That is a 25% increase in the ratio without an extra dollar of earnings. The impression count is 20% lower. The percentage changes differ because their denominators differ.

Write the formula beside the chart. Do not substitute page views for ad impressions: page RPM answers a different question. A report that labels both simply “RPM” invites the wrong conclusion during a measurement transition.

Keep counting, viewability, and earnings separate

Beginning to render does not by itself establish that the placement was visible to the reader. Equally, an ad-server browser event is not a substitute for the platform’s finalized reporting. Keep those records linked, but do not merge them into one success count.

Prepare a baseline without changing the site

Choose a stable reporting window and document timezone, currency, inventory scope, and filters. Export the available comparable metrics. Keep desktop and mobile rows separate initially so a change in device mix cannot masquerade as a change in rendering.

Download the impression-counting baseline worksheet (CSV). The two worked rows are synthetic and marked EXAMPLE-REMOVE. They demonstrate denominator arithmetic only. Replace them with reports from your own account; leave unavailable metrics blank rather than estimating them.

Save the original export separately from the calculation sheet. Record the report-generation time as well as the dates covered. That makes later reconciliations possible if reporting values are revised.

Investigate the gap before changing ad loading

When a difference appears, first ask whether the two columns cover the same inventory and period. Then isolate which placements, devices, or creatives account for most of the absolute difference. A 50% gap on a tiny placement can matter less commercially than a 5% gap on the largest one.

For a suspect placement, capture a normal page load and check whether the reader can continue using the page comfortably. Record failed requests, missing creative content, and visible instability. Treat an early departure as an observation, not proof that the creative caused it.

Avoid making the page heavier merely to make a counting metric look better. Test one loading change at a time on a controlled page and compare user experience as well as reporting. A change that increases counted inventory while frustrating readers is not automatically an improvement.

Do not mix this with September’s bfcache change

The separate Google Publisher Tag bfcache refresh announcement concerns what happens when a reader returns to a cached page. It has a different effective date and mechanism. One concerns a refresh trigger; the other concerns the counting point.

Annotate each event separately in your reporting calendar. Keep traffic, ad requests, counted impressions, viewability, and earnings in distinct columns. Use our site-audit sequence when ad changes also affect page stability or loading.

Source checked September 4, 2026. The worksheet and arithmetic are SearchEngineAnswer’s explanatory contribution, not a publisher benchmark or a revenue forecast.

What the shopping study measured

Productrise’s study covered August 9–31, 2026, using more than two million listings from over 100,000 search results and AI Mode responses in the US and UK. It matched Google product IDs for the same query and day, then compared first-listed offers. Traditional search sampling used the Popular products carousel; AI Mode sampling included tracked product cards.

Among matched products, the first seller differed in 49.6% of cases and the price differed in 38.1%. Within the price-different subset, AI Mode was higher 68.4% of the time. Productrise reported a 21.6% average premium across matched pairs, but condition differences and outliers complicate that average.

This is a commercial tracking vendor’s observational sample, not a random sample of all shopping searches. It does not establish purchases, clicks, or Google’s ranking mechanism. SearchEngineAnswer has not independently reproduced the dataset.

Product identity is only the first check

Consider a hypothetical kettle with the same model number in two results. One leads to a used unit for $80; the other leads to a new unit for $100. The displayed difference is 25%, calculated against $80. Calling it a 25% markup on an equivalent offer would hide the condition difference.

Now consider two new units at $100 and $105. If the first seller charges $15 shipping and the second includes delivery, the displayed item-price comparison and the delivered-price comparison point in opposite directions. These are illustrative arithmetic examples, not observations from Google’s results.

For a retailer, those distinctions determine the next action. A wrong condition deserves a data correction. A valid competing offer deserves a commercial review. Neither justifies changing every product price because of an aggregate headline.

Classify the discrepancy before escalating it

Build a small, reviewable offer record

Start with products for which your team can verify stock, variants, and delivery terms. Record the exact query, country, time, surface, product identifier, seller, condition, currency, displayed price, and destination URL. Open the destination and record whether the advertised variant is actually available.

Save both result captures together. Mark shipping or tax as unknown when it cannot be verified without an address or checkout. Do not fill unknown fields with zero. A zero shipping charge is a claim about the offer; a blank field is a limit of the observation.

Download the offer-comparison worksheet (CSV). Its example pairs are explicitly labeled EXAMPLE-REMOVE. Replace them with dated observations. The worksheet separates item-price differences from delivered totals and includes a reason to reject an invalid match.

Separate visibility from the checkout outcome

Repeat the same product-query pairs before deciding that a seller change is persistent. Count comparable pairs separately from all captured pairs. If ten of twenty captured pairs have unresolved variant or delivery differences, your equivalent-offer analysis has ten observations, not twenty.

Track product presence, seller presence, displayed price, landing-page consistency, and attributed orders separately. A screenshot can establish what appeared at that moment. It cannot tell you which seller the shopper ultimately chose.

Our Google AI Mode checkout explainer covers a later part of that journey. The visibility and referral-traffic framework explains why appearances should not be reported as visits or sales.

What to change now

Use the worksheet to create an exception list: wrong condition, wrong variant, stale price, unavailable offer, incomplete delivery information, or a valid alternative seller. Assign each exception to the person who can resolve it. Preserve a before-and-after capture when a correction is made.

The useful conclusion is narrower than “AI Mode prefers expensive products.” Retailers now have a reason to inspect which offer represents their product on each surface. Our contribution is that offer-level review process; it is not a new measurement of Google’s behavior.

429 and 503 answer different questions

The September 2, 2026 API changelog says rapidly growing traffic may receive HTTP 429 with slow_down. A temporary model overload may receive HTTP 503 with server_is_overloaded. OpenAI says either response may include Retry-After and recommends honoring it; without the header, clients should use exponential backoff.

Build the retry policy in this order

1. Parse the HTTP status, structured error code, request ID, and Retry-After.
2. If the response is not in an approved transient class, stop and route it to the appropriate failure handler.
3. If Retry-After is valid, wait for that duration unless it exceeds the job’s total time budget.
4. Otherwise calculate exponential backoff with randomized jitter.
5. Cap the attempt count, per-wait delay, and total elapsed time.
6. For write-like or externally visible tools, use an idempotency strategy before retrying.

if retry_after_is_valid:
    delay = retry_after
else:
    delay = min(max_delay, base_delay * 2 ** attempt) + jitter

if attempts_exhausted or elapsed + delay > job_budget:
    stop_or_defer()
else:
    retry_after(delay)

This pseudocode is a design pattern, not an official SDK sample. Use your runtime’s current OpenAI SDK and header parser.

Jitter prevents clients from retrying together

Pure exponential backoff can synchronize a fleet: many workers fail together, calculate the same delay, and return together. Random jitter spreads the retries. Use a documented strategy such as full jitter or equal jitter and test it with a fake clock.

Do not sleep inside a request thread if the architecture can reschedule work. A durable queue can preserve the task, earliest retry time, attempt count, and idempotency key without tying up capacity. Interactive requests should have a short user-facing budget; long research batches can defer instead of making the user wait through repeated attempts.

Log a decision ledger, not just an error count

Download the OpenAI API retry decision ledger (CSV). Its rows are marked EXAMPLE-REMOVE and contain no production results. Redact credentials, prompts, personal data, and raw output before sharing a real ledger.

Capture event time, endpoint, model, status, error code, retry header, attempt, chosen delay, decision, outcome, and latency. Store the request ID in a restricted operational log. The key derived metrics are not merely “errors per hour”:

• first-attempt success rate;
• recovered-after-retry rate by status and code;
• requests abandoned by attempt cap or elapsed-time cap;
• added latency among successful requests;
• duplicate side effects prevented or detected;
• measurement rows lost, deferred, or completed.

Protect AI visibility measurements from retry bias

A visibility study can become biased when failed prompts disappear from the denominator. If one model or query class overloads more often, analyzing only successful answers can make it look more reliable or more visible than it was.

Pre-register the query set and keep every scheduled row. Mark outcomes as completed, recovered, deferred, permanently failed, or excluded with reason. Report the completion rate next to citation and recommendation rates. Our AI visibility and referral test uses the same denominator discipline.

For cost governance, the OpenAI API cost-by-key ledger can be joined on a hashed job ID. Do not assume a failed or retried request was free; use billing telemetry where available and otherwise mark the cost unknown.

Alert on impact and classification

Use separate time series for 429 slow_down, 503 server_is_overloaded, other 429 codes, and other 5xx errors. Alert on sustained user impact, depleted retry budgets, queue age, or completion-rate loss; not on one transient response.

A sudden 429 slow_down increase after a client deployment points first to traffic shaping and concurrency. A 503 overload increase isolated to one model suggests a different investigation. These are operational hypotheses, not proof; the request logs and OpenAI status information provide the evidence.

Never create an infinite retry loop. It converts a brief constraint into added load, higher latency, and a misleading success metric.

Review the policy after traffic-shaping, concurrency, queue, SDK, or model-routing changes because each can alter the retry pattern without any change to the underlying content workload.

Source, method, and update note

Primary source: OpenAI’s API changelog, September 2 entry, checked September 3, 2026.

Method: SearchEngineAnswer translated the documented status and error-code distinction into a retry and monitoring workflow. We did not run a load test and report no incident rate or recovery-rate benchmark.

Recheck trigger: Update if OpenAI changes the error codes, retry guidance, response headers, status semantics, or SDK behavior.

What Cloudflare says will change

Cloudflare’s documentation separates automated traffic into Search, Agent, and Training purposes. Each purpose can be configured as Allow, Block pages with ads, or Block all. The controls are available under Security Settings in the AI bot policies configuration.

For domains added on or after September 15, Cloudflare documents these defaults: Search allowed; Agent blocked on pages with ads; Training blocked on pages with ads. Customers can opt out before the date. The legacy “Block AI Bots” control is scheduled for deprecation on September 15 as the purpose-based settings take over.

Existing domains need an explicit read

The announcement describes defaults for new domains. It does not establish that an existing domain’s current policy will be rewritten to match. Open the domain’s AI bot policy screen and record all three settings rather than copying the new-domain table into an audit.

Also capture whether the domain used the legacy Block AI Bots switch, when it was added to Cloudflare, and whether a person or API last changed the policy. A screenshot is useful, but export or transcribe the values into a dated ledger so they can be compared after the rollout.

For content-use declarations at the crawl endpoint, see our Cloudflare /crawl Content Signals guide. That endpoint contract and the bot-management defaults are related publisher controls, but they are not the same enforcement surface.

Test mixed-purpose bots as their own case

Cloudflare says bots classified as both Search and Training are blocked under configurations that block AI training, including the legacy Block AI Bots control. This mixed-purpose rule is important because “Search is allowed” does not necessarily override a Training restriction.

Do not generalize the classification from a vendor name. Record the specific bot, Cloudflare’s observed category, request path, page ad state, rule matched, and action. If the purpose is unknown or classification changes, mark the row inconclusive until evidence is available.

The broader AI crawler decision guide helps align access choices with business goals, while the ChatGPT robots controls guide covers a product-specific layer outside Cloudflare’s classification.

Run the pre- and post-rollout audit

Download the Cloudflare AI bot pre/post audit (CSV). Its rows are marked EXAMPLE-REMOVE. The September 16 rows are test fixtures, not observations.

1. Before September 15, save the domain creation date and each purpose setting.
2. Record whether representative pages contain ads and how ad presence is detected.
3. Preserve the legacy-control state and any custom WAF or bot rules that can affect the same request.
4. After rollout, create a controlled new domain or zone only if your account and policy allow it.
5. Observe Search, Agent, Training, mixed-purpose, and unknown classifications separately.
6. Save request time, bot identity, classification, matched rule, action, and response evidence.
7. Compare expected defaults with observed configuration before testing network behavior.

A failed request does not by itself prove the AI bot policy caused the failure. DNS, origin availability, authentication, robots rules, rate limits, WAF rules, and custom firewall logic can produce similar symptoms.

Choose policy by purpose, not by fear

Search retrieval may create discovery or citation opportunities. Agent access may serve a user who asks a tool to fetch your page. Training may create a different value exchange. A single “AI bot” toggle hides those distinctions.

Assign an owner and written intention to each purpose. If ad-funded pages require a different policy, define how the site labels those pages and test the label. If training is never authorized, use the explicit block-all control instead of relying on the ads condition.

Do not promise that allowing Search will cause indexing, citation, ranking, or referral traffic. Access is only the first state in the chain.

What can be published before and after September 15

Before rollout, publish the documented defaults, your current configuration, and the planned test. Label future rows “expected” or “not observed.” After rollout, add an observed result only when the domain cohort, configuration, request evidence, and confounding rules are preserved.

If observed behavior differs from the documentation, report the mismatch and conditions rather than declaring the documentation wrong. Account rollout timing, domain age, configuration inheritance, or classification can explain a difference.

Source, method, and update note

Primary source: Cloudflare’s Block AI bots documentation, checked September 3, 2026.

Method: SearchEngineAnswer converted the documented future defaults into a pre/post audit. We have not observed the September 15 rollout and report no live block rate.

Recheck trigger: Verify after September 15, then update only with reproducible observations. Recheck sooner if Cloudflare changes the date, defaults, purpose definitions, mixed-purpose handling, or legacy-control deprecation.

Breaking point one: forced tool choice

Anthropic documents that Fable 5.1 does not support forced tool selection. A request using tool_choice: {"type":"any"} or explicitly naming a tool returns an invalid_request_error with HTTP 400. auto and none remain supported.

This is easy to miss in an agent framework that silently injects forced choice after application code builds the request. Search serialized payloads, SDK middleware, routing layers, and stored prompt templates; not just the visible call site.

// Migration pattern: let the model choose, constrain the shape.
tool_choice: { type: "auto" }
// Pair with strict tool schemas or structured outputs where appropriate.

That pattern does not guarantee a tool call. If the workflow requires a specific deterministic operation, validate the model’s decision and handle a no-tool response explicitly. Do not retry the same invalid forced-choice payload.

Breaking point two: thinking-block compatibility

Fable 5.1 can read thinking blocks created by earlier Claude models. The reverse route is not compatible: earlier models cannot read Fable 5.1 thinking blocks. That makes a simple “try 5.1, then replay the full response to an older fallback” unsafe.

Anthropic says incompatible thinking blocks can be dropped when the relevant beta behavior is not enabled. With the beta header, transformations are recorded in input_transformations. Either way, the application should treat the route as a versioned transcript conversion, not as a transparent retry.

Keep conversation history append-only

Editing or deleting an earlier turn can invalidate the relationship between thinking blocks and the conversation that produced them. Redaction, summarization, memory compaction, and “helpful” message normalization therefore need tests.

Store an immutable raw transcript for replay and create a separate derived context when policy requires transformation. Record which messages were dropped, summarized, or redacted. A hash of the ordered input messages gives operations teams a way to detect a hidden mutation without storing more sensitive content in logs.

For workflows that browse, our Claude domain-allowlist guide separates access controls from source quality. The same principle applies here: a valid transcript is necessary, but it does not establish that a tool result is authoritative.

Run an eight-fixture migration gate

Download the Claude Fable 5.1 migration matrix (CSV). The included rows are marked EXAMPLE-REMOVE and describe tests to run; they are not production results.

1. Confirm forced named-tool and any requests fail before a tool can execute.
2. Test auto with one prompt that should call a tool and one that should not.
3. Validate strict schemas with valid and invalid arguments.
4. Replay an earlier-model transcript into 5.1.
5. Exercise the 5.1-to-older fallback path using a controlled transformation.
6. Edit a historical turn and confirm your guard rejects or rebuilds the context.
7. Verify that HTTP 200 responses with stop_reason: refusal do not enter the normal success path.
8. Test maximum elapsed time and cost controls on long-context jobs.

Treat refusal, retention, and price as separate controls

Anthropic documents that a refusal may arrive with HTTP 200 and stop_reason: refusal. A status-only health check can therefore record success while the application received no usable completion. Count transport success, model completion, refusal, tool success, and business success separately.

The documented price is $10 per million input tokens and $50 per million output tokens, with cache reads at $0.25 per million and cache writes at $12.50 for five minutes or $20 for one hour. Recalculate budgets from actual input, output, and cache telemetry; do not assume the larger context window should be filled.

Anthropic also documents 30-day retention and says Zero Data Retention is not the default unless expressly authorized. Verify the contract and product configuration for your account before sending sensitive data. Capability, cost, and retention are three independent release gates.

Roll out with a one-way canary

Begin with stateless or single-turn work. Then canary multi-turn conversations that stay on 5.1. Add cross-model fallback only after the transformation path passes. This order makes the incompatible direction visible instead of discovering it during an incident.

Pin the model ID, SDK version, tool schema version, transcript policy, and fallback model in the release record. The Claude search-result-blocks guide offers a compatible evidence pattern for tool-derived content.

Source, method, and update note

Primary sources: Anthropic’s Fable 5.1 migration notes and release notes, checked September 3, 2026.

Method: SearchEngineAnswer converted documented incompatibilities into an unrun migration matrix. We did not benchmark the model or execute production tools.

Recheck trigger: Update if Anthropic changes tool-choice support, thinking compatibility, retention, context limits, pricing, or refusal semantics.