Direct answer
On November 2, 2026, Cloudflare changed the default scheduled sync interval for AI Search website and R2 external data sources from six hours to 24 hours. Teams can still select an interval from 15 minutes to 24 hours or trigger a job after a CMS publish or build completes. Global brands should not switch every instance to 15-minute polling. Classify price, availability, policy, product, evidence and evergreen content by freshness risk; trigger high-risk changes from publish events, keep scheduled sync as a fallback, and validate the job, indexed item and cited answer separately. This change affects a private Cloudflare AI Search index, not Google, Bing or ChatGPT public-search crawl and citation timing.
Facts and background
On November 2, 2026, Cloudflare announced that the default scheduled sync interval for AI Search instances connected to a website or R2 external data source is changing from six hours to 24 hours. Operators can still select 15 minutes, 30 minutes, one hour, two hours, four hours, six hours, 12 hours or 24 hours in the dashboard. The API uses sync_interval values of 900, 1800, 3600, 7200, 14400, 21600, 43200 and 86400 seconds, with 86400 now the default.
The same update postponed AI Search billing from November 1 to December 1, 2026 without changing prices or included usage. These are separate decisions. Sync interval determines how often an external source is scheduled for scanning; the billing date determines when resource use beyond included amounts starts to incur charges. A billing delay does not remove freshness risk, and a scheduled scan should not automatically be described as a full re-ingestion charge.
What the 24-hour default changes
| Layer | Current official behavior | Brand decision | It does not establish |
|---|---|---|---|
| Scheduled sync | Website and R2 sources run every 24 hours by default | Which instances can tolerate a roughly day-long scheduled wait | A fixed completion time or a guarantee that every change is searchable within 24 hours |
| Configurable interval | Eight intervals from 15 minutes to 24 hours are supported | Choose by content risk, scale and origin capacity | A shorter interval automatically improves answer quality |
| Event trigger | A CMS, pipeline or API can create a sync job after content changes | Which real publish events trigger and how duplicate events are merged | A created job means the final answer is current |
| Built-in storage | Uploaded files are processed individually without scheduled jobs | Whether urgent corrections need upload or single-file re-indexing | Immediate processing guarantees citation |
| Inactivity pause | External-source instances pause scheduled jobs after 31 days without a search request | How to monitor, resume and reconcile paused changes | The instance is unsearchable; Cloudflare says it remains searchable |
The 24-hour default is not a service-level commitment. A job must discover changes, fetch source content, parse files, create chunks, generate embeddings and update the index. File count, file type, image processing and model latency affect completion time. For price, availability, recall notices, compliance declarations, service coverage and delivery policy, scheduled sync alone can leave a customer assistant, distributor agent or procurement tool citing an old fact.
Classify fact risk before choosing a sync strategy
| Content tier | Typical changes | Suggested trigger | Acceptance focus |
|---|---|---|---|
| Transaction and availability | Price, currency, stock, delisting, delivery region and lead time | CMS, PIM or commerce event plus scheduled fallback | Variant identity, current value, deletion state and target market |
| Risk and compliance | Recall, safety notice, certificate status, policy and terms | Trigger immediately after publish; use single-file re-indexing when needed | Old versions stop appearing and scope and effective date are correct |
| Product and technical facts | Model specifications, compatibility, manuals, API versions and service boundaries | Publish event or one- to six-hour schedule | Model, market, language, version and source URL remain traceable |
| Brand evidence and analysis | Cases, tests, media records and research updates | Publish event or six- to 24-hour schedule | Evidence status, date, limitation and citation link |
| Evergreen knowledge | Definitions, methods, basic FAQs and history | A 12- to 24-hour schedule is usually sufficient | Sample retrieval and periodic review instead of constant scans |
Put the strategy in a URL- or content-type-level fact ledger instead of leaving it only in the Cloudflare dashboard. Record the owner, fact risk, maximum allowed staleness, source, trigger, instance, language, market, latest publish, latest successful index, sample query and rollback version. This separates source failures, job failures, blocked crawling, parsing errors, stale index entries and retrieval misses.
Use CMS events to reduce delay for high-risk facts
Cloudflare documents programmatic job creation after a CMS publish event or build. A job can be triggered at most once every 30 seconds, so a pipeline should merge closely spaced events for the same instance instead of creating a job for every small field edit. Send the event only after the content transaction commits, the public URL returns the intended version and visible facts pass validation.
Save content → validate fields and links → commit public release → create sync job
→ store job ID → wait for completion → inspect Items → run freshness queries
A trigger sent before a static release, CDN purge or database transaction completes can fetch the old page. Retries without an idempotent version key or merge window can create a job storm. Use the content version or publish transaction as the correlation key and retain the URL set, request time, job ID, terminal state and indexed version. Apply bounded retries and alerts to failures.
A successful job is not an updated answer
| Evidence layer | Record | It establishes | It does not establish |
|---|---|---|---|
| Source publish | Public URL, version, field hash and publish time | The authority page changed | AI Search read it |
| Sync job | Job ID, start, finish, state, logs and errors | The job ran and reports a result | Every target URL produced a correct index item |
| Index item | Item, source URL, update time, parsed content and metadata | The intended version entered the instance | A query will select it |
| Retrieval and answer | Fixed question, returned chunk, citation, time and model configuration | Retrieval and citation under the tested configuration | Public search engines or third-party AI systems also updated |
| Business outcome | Sessions, referrals, leads, orders and error reports | The result in the owned experience | Sync interval alone caused the change |
AI Search can expose source chunks and URLs in an answer, but source display depends on retrieval results, generation settings and application implementation. After a high-risk update, run one positive question that should return the new fact, one negative question that must not return the old fact, and one market or language boundary question. A green job state does not reveal wrong variants, stale cache, incomplete parsing or an obsolete source still being selected.
The 31-day inactivity pause is a second freshness boundary
Cloudflare says an external website or R2 instance automatically pauses scheduled sync jobs after 31 days without a search request. The instance remains searchable, but source changes are not picked up while scheduled jobs are paused. New search or chat activity resumes jobs during activity checks, and operators can resume them manually.
This matters for seasonal markets, distributor portals, event knowledge bases and low-frequency internal assistants. An instance unused for months may still answer when traffic returns while holding an old product or policy version. Before relaunch, inspect the paused state and last successful job, resume when needed and reconcile all changes made during inactivity. A working answer is not proof of a current index.
Postponed billing does not change cost governance
Cloudflare postponed AI Search billing to December 1, 2026. Current included monthly usage is five million ingestion tokens, 10 GB-month of storage, 1,000 semantic queries and 1,000 full-text queries per account. Ingestion tokens are counted on final chunks after parsing and chunking, and overlap repeats text across chunks. Image and scanned-document processing has a separate image-processing ingestion rule.
Do not assume that more frequent scanning is always better, or that every scheduled scan re-bills the entire corpus. Observe actual changed content, ingestion usage, storage, query volume and errors before choosing intervals, event scope, chunking and cleanup. Cost reduction should not delay high-risk facts, and freshness should not rely on indiscriminate high-frequency scanning.
Freshness acceptance before and after release
| Decision | Condition | Action |
|---|---|---|
| Pass | Public version is correct; job completes; Item contains the current version; positive, negative and boundary queries pass; source URL resolves | Record version, job and query evidence and enter routine monitoring |
| Conditional pass | Job and Item are correct but a market, language or low-priority query remains untested | Limit scope until the missing test passes |
| Fail | Old facts remain retrievable, deleted content stays indexed, WAF blocks crawl, a job fails or the source link is wrong | Stop treating the instance as an authority answer source, repair and rerun |
| Not attributable | Only an answer change exists without source version, job, Item or query controls | Do not claim improvement; rebuild the evidence chain |
The move from a six-hour to a 24-hour default should upgrade the publishing architecture, not just a dashboard setting. Use events for time-sensitive facts, scheduled sync for fallback, job and index evidence for auditability, and fixed questions for outcome acceptance. Connecting these four layers prevents an owned AI search experience from amplifying old facts after the website has changed.
Business impact
First, multilingual and multi-market sites that keep the default now face a longer scheduled wait, from six to 24 hours. Price, stock, delivery scope, compliance status and product versions can remain stale in owned customer assistants, distributor tools or procurement agents, especially across time zones and batch releases. Second, CMS, PIM, commerce and knowledge-base events need one index pipeline. Brands must correlate content versions, sync jobs, index items and sample answers to locate a fault in source data, crawl, parsing, indexing, retrieval or generation. Third, 31 days without a search request pauses scheduled syncs for external sources. Seasonal services, low-traffic markets and internal tools may still answer from an old index; teams must check pause state, last successful job and all changes made during inactivity before reuse. Fourth, billing from December 1 requires joint freshness and cost governance. Measure interval, actual changes, chunk overlap, image and OCR use, storage and query volume separately. Do not replace content tiers with frequent global scans, and do not delay high-risk facts only to reduce usage.
Zhihe Growth assessment
Zhihe Growth sees the main change as a shift of responsibility from default polling to event-driven publishing for time-sensitive knowledge. The right architecture for a global brand is: an authority source owns versions, a CMS transaction creates the event, an AI Search job updates the index, and fixed questions plus source URLs accept the result. Define four staleness classes. Transaction and safety facts use minute-level event triggers; product and policy facts use publish events or hourly schedules; evidence and analysis use six to 24 hours; evergreen knowledge uses 24 hours plus periodic review. A completed job is program evidence, not a substitute for Item inspection, positive and negative questions or citation-link checks. Measure Cloudflare AI Search separately from Google, Bing, ChatGPT and other public discovery systems. AI Search is an owned instance with its own source, index and retrieval workflow. Each public platform has independent crawlers, indexes, product data and citation systems. Success in one does not prove crawl, indexing or citation in another.
Recommended actions
- Inventory every AI Search instance with its source, current `sync_interval`, last successful job, last query time and pause state.
- Define maximum staleness and an owner for price, stock, delisting, policy, compliance, product facts, evidence and evergreen content.
- Connect CMS, PIM or build release transactions to sync jobs only after the public version passes validation.
- Merge events for the same instance over at least 30 seconds and use a content version or release transaction as the idempotent correlation key.
- Keep the 24-hour schedule as a fallback; shorten it only when risk and capacity evidence justify the change.
- For every high-risk update, retain job ID, logs, affected URLs, Item version, success and failure counts and completion time.
- Build positive, negative and market or language boundary queries for each update class and inspect chunks, source URLs and obsolete facts.
- Add pause alerts, a resume runbook and pre-launch freshness checks for seasonal or low-frequency instances that may go 31 days without queries.
- From December 1, monitor ingestion tokens, chunk overlap, image and OCR processing, storage, semantic or hybrid queries and full-text queries separately.
- Report source publish delay, sync delay, index correctness, retrieval freshness, source accuracy and business outcomes as separate monthly metrics.
Limitations
This article reflects Cloudflare announcements and AI Search documentation accessible on November 3, 2026. The 24-hour default applies to website and R2 external data sources. Files in built-in storage are processed individually on upload and do not use scheduled sync jobs. Supported intervals, billing dates, included usage, limits and APIs may change; verify the production instance and current official documentation. A created or completed sync job does not guarantee that every URL was parsed correctly, any query will retrieve the new content, an answer will display its source, or Google, Bing, ChatGPT and other public AI-search systems updated. Index freshness, public-search indexing, AI citation and business conversion require separate evidence.