Apple Just Gave Applebot 4,656 New IP Addresses. A Third Search Engine May Be Warming Up.

No announcement, no changelog, and a 194% jump in the crawler’s published address pool. Meanwhile, any allowlist built before August 17 now misses two-thirds of Applebot’s traffic. Here is what the numbers say, why the pattern echoes OpenAI’s search launch, and what to do before Cloudflare’s September 15 default lands.

On August 17, 2026, Search Engine Roundtable reported a change logged by a crawler-monitoring tool run by the London SEO consultancy Merj, in a small JSON file most webmasters never look at. Apple’s published list of Applebot IP ranges had grown from 12 network blocks to 33. That is 4,656 new IP addresses in a single update, with no announcement, no blog post, and no explanation from Apple (Search Engine Roundtable, PPC Land).

I fetched Apple’s JSON file directly on August 18 and verified every prefix and the arithmetic below. Applebot is the crawler behind Spotlight, Siri, and Safari search. On its own, an IP allocation is boring infrastructure. What makes this one worth your attention is the pattern, the timing, and one immediate operational problem: if your firewall or bot-management rules still reference Apple’s old 12-prefix list, they now misclassify most of Apple’s advertised crawler traffic.

What actually changed in the file

Before the update, Apple’s crawler verification file listed 12 IPv4 prefixes totaling 2,400 addresses: nine /24 blocks and three /27 blocks, scattered across three unrelated neighborhoods (17.22.x, 17.241.x, 17.246.x). The new file lists 33 prefixes totaling 7,056 addresses. The pool did not roughly double. It nearly tripled.

The structure of the addition matters more than the raw count. The old prefixes sit in three separate second-octet ranges, the kind of footprint that accumulates over time across different facilities. All 21 new prefixes fall inside a single block, 17.166.0.0/16, and they arrive in tidy consecutive runs: 17.166.20.0 through 17.166.25.0, 17.166.150.0 through 17.166.155.0, and 17.166.232.0 through 17.166.237.0, plus three /28 blocks. That reads as a single allocation carved out in one pass, which is the signature of deliberate provisioning rather than housekeeping.

One number deserves a caveat. Address count is not crawl capacity: a single machine can serve from many addresses, and many machines can share one. What the allocation does establish is intent to distribute requests across a much wider surface than before, which is the pattern operators use when parallel fetching is about to increase.

Why this pattern reads like a warm-up

The change was spotted by Ryan Siddle, an SEO and AEO partner associated with Merj, whose monitoring tool produced the alert. His read of the pattern:

“We’ve seen on several occasions OpenAI ramp up their IPs to warm the servers. The most recent was the Sol 5.6 release, but it wasn’t at the scale Apple just did. Apple also hadn’t updated their IPs for many years.”

That is a comparison from Merj’s own historical observations, not an operator disclosure, and Merj sells the monitoring product that produced the alert. But the sequence around Apple’s crawler is hard to ignore:

Put the pieces together and the inference is straightforward, even if Apple has not confirmed it. A crawler that must supply fresh grounding data for an assistant answering open-ended questions needs a very different fetch profile from one populating Spotlight suggestions. Apple has shipped the assistant (iOS 27 public beta), signed the model deal (Gemini), rewritten the crawler’s mandate (June 8 documentation), and now tripled the crawler’s address pool. As of August 18, the r/SEO thread about the IP expansion has zero comments. Nobody has written the readiness playbook yet. This is.

The distribution stakes are what separate Apple from every other new search entrant: more than 2 billion active devices, per Apple’s own reporting since 2023, with Siri, Spotlight, and Safari suggestions already wired into the OS. There is no install required for a user to start getting web answers from Apple. There is only a crawl that needs to find your content first.

Your allowlist is probably already broken

Here is the part with immediate operational consequences. If you whitelisted Applebot by its published CIDR ranges before August 17, your rules were built on 12 prefixes. Those 12 prefixes now cover only about a third of the addresses Apple advertises.

It gets messier. Apple’s support page presents two verification methods as if they were equivalent: reverse DNS into *.applebot.apple.com, or matching against the CIDR file. They are not. The documentation’s own worked example resolves 17.58.101.179 to 17-58-101-179.applebot.apple.com. That address does not fall inside any of the 33 prefixes in the published file. Apple’s own example of legitimate Applebot traffic would fail a strict CIDR check against Apple’s own list (Apple, “About Applebot”, verified live on Aug 18).

There is also a timestamp problem. The JSON file carries a creationTime of July 31, 2026, but the change was only detected on August 17. Any monitoring keyed off that timestamp, rather than diffing the prefix list itself, slept through a two-week window. The file has no version number, no changelog, no differential. Google moved its crawler IP files to a daily refresh cycle in March 2025 precisely to shrink this kind of gap; Apple publishes current state without publishing change.

And user-agent strings alone were never a safe bet. Research covered in January 2026 found AI agents presenting spoofed user-agent strings to bypass site defenses, with one chatbot query triggering sixteen requests from twelve addresses impersonating human browsers (per PPC Land’s coverage). Verification needs both reverse DNS and forward-confirmed lookup, with the CIDR list treated as a supporting signal, not the whole answer.

The September 15 collision

One date now sits directly in Apple’s path. From September 15, 2026, Cloudflare will block crawlers classified as Training and Agent by default on advertising-carrying pages for new domains onboarding to its network. Multi-purpose crawlers are judged by their most restrictive behavior, and Applebot is named explicitly in that list, alongside Googlebot and BingBot.

Apple’s own June 8 documentation is what puts it there: the page states crawled data may train Apple’s foundation models, which is precisely Cloudflare’s definition of a multi-purpose crawler. So a crawler that gained address capacity in August meets a default-block wall in September. If your site is on Cloudflare and you have ever toggled “block AI training crawlers,” check what that toggle actually does to Applebot before the 15th.

The cost of blocking is not theoretical. Research from Rutgers Business School and The Wharton School, revised in April 2026, found news publishers who blocked LLM crawlers via robots.txt lost roughly 7 percent of weekly traffic within six weeks. The cost of unlimited automated access is real too: Cloudflare’s attribution dashboard (opened July 1) shows crawl-to-referral ratios from 118:1 up to nearly 50,000:1 across AI crawlers, and TollBit measured about 15 percent of identified page-fetching agents in Europe reaching URLs they had been told to avoid (both figures per PPC Land’s reporting). This is a decision, not a default, and it should be made deliberately for Apple’s crawler the same way it was made for OpenAI’s and Anthropic’s.

How Applebot actually behaves

The June 8 documentation rewrite quietly defined three independent controls, and the independence is the point. Most sites will only configure the first one and assume it does everything. It does not.

Several operational details in the same document will shape how the new capacity feels on your servers:

Applebot inherits your Googlebot rules. Where robots.txt says nothing about Applebot but addresses Googlebot, Applebot follows the Googlebot instructions. A large share of the web is governing Apple’s crawler with rules written for someone else, without knowing it. If you blocked Googlebot from a section years ago for crawl-budget reasons, you have probably blocked Applebot too.

Applebot ignores crawl-delay. Apple states the crawl rate adjusts automatically when a site slows or returns errors, and that content is cached to reduce repeat fetching. If you throttle bots via crawl-delay, that lever does not exist here; server-side rate handling is your only feedback loop.

It renders pages in a browser. Apple notes Applebot may execute pages in a browser, and blocking JavaScript, CSS, or XHR resources via robots.txt can prevent proper rendering. The same rule that hurts you in Google’s renderer hurts you here.

Paywalls get a page-level signal. Marking structured data with isAccessibleForFree: false keeps a page eligible for search results while excluding its content from AI-generated answers. Section-level markup via hasPart is not supported.

Ranking factors, as stated by Apple: aggregated user engagement with search results, relevancy matching between query and page content, the number and quality of inbound links, approximate location signals, and webpage design characteristics, with no predetermined weighting among them. Entity-rich, well-structured content with clear topical relevance is exactly what that list rewards.

There is no Apple Search Console. No query-level reporting, no impression counts, no coverage tools. Server logs are the primary evidence available, and server logs depend on correct crawler identification, which is exactly the problem the previous section described.

The Applebot readiness checklist

Eight things to do this week, in order of priority. None of them require deciding whether Apple will become a search giant; they are correct under any version of that future.

1. Refresh your CIDR allowlist today. Pull search.developer.apple.com/applebot.json and diff the prefix list itself. Do not trust the creationTime field; it read July 31 while the change surfaced August 17.
2. Verify Applebot with reverse DNS plus forward confirmation. Resolve the requesting IP to *.applebot.apple.com, then resolve that hostname back to the same IP. Treat the CIDR file as a supporting check, not the only check, since Apple’s own documented example IP (17.58.101.179) is absent from it.
3. Audit your robots.txt for what it actually tells Apple. No Applebot block means your Googlebot rules apply by default. Add an explicit User-agent: Applebot section so the decision is yours.
4. Make the Applebot-Extended call before the ramp, not after. If your content must not train Apple’s foundation models, disallow Applebot-Extended now. Remember it does not stop crawling or indexing.
5. Use nosnippet where answers should not quote you. Meta tag for HTML, X-Robots-Tag: applebot: nosnippet for PDFs and images. Paywalled pages: add isAccessibleForFree: false in JSON-LD.
6. Let the renderer in. Do not block the JS, CSS, or XHR resources your pages need to render. Graceful degradation helps, but full access is what gets indexed faithfully.
7. Check your Cloudflare settings before September 15. If you block Training-classified crawlers, Applebot is in that category for ad-carrying pages on new domains. Decide explicitly whether Siri and Spotlight visibility are worth allowing it.
8. Start a log baseline now. Count Applebot requests per day, identify them correctly (step 2), and track the trend weekly. When there is no Search Console, your access logs are the dashboard. A spike is how you will know the ramp has started; one anonymous site owner on the Search Engine Roundtable report already claims roughly 4,000 Applebot visits in a day, unverified, but that is the shape of signal to watch for.

What Apple has not said

For completeness, the honest part. Apple has given no reason for the expansion, no indication whether crawl volume will rise, and no connection between the allocation and any product. The support page lists applebot@apple.com as the contact address and carries no revision note since June 8. The “third search engine” reading is an inference from documentation, timing, and allocation structure. It is consistent with every observable fact, and it is still an inference. A smaller reading is also possible: Apple is simply giving an existing, undersized crawler room to work. Cloudflare’s January 2026 data had Googlebot reaching 14.87 times more unique URLs than Applebot, so even after tripling, Applebot remains a small player in absolute terms. The difference is that the infrastructure constraint is now gone, and the product that needs the crawl is already in public beta.

Either way, the operational facts do not depend on Apple’s intentions. Your old allowlist covers a third of the published pool. Your robots.txt is probably governing Applebot through Googlebot rules you forgot about. And on September 15, a popular CDN may start blocking it for you by default. Those are fixable this week.

Sources

• Applebot IP CIDR file, fetched and verified Aug 18, 2026 (33 prefixes, creationTime 2026-07-31)
• Apple, “About Applebot”, published June 8, 2026 (control layers, verification methods, ranking factors)
• Search Engine Roundtable, “Apple Adds Applebot/Siri Thousands Of New IP Addresses”, Aug 17, 2026
• PPC Land, “Apple adds 4,656 IP addresses to Applebot crawler in one update”, Aug 17, 2026 (prefix analysis, Cloudflare dates, TollBit and Rutgers/Wharton figures)
• Ryan Siddle (Merj), LinkedIn post, Aug 17, 2026, quoted via Search Engine Roundtable
• r/SEO thread, Aug 17, 2026 (0 comments as of Aug 18)
• Bloomberg, “Apple Plans AI-Powered Web Search Tool for Siri to Rival OpenAI, Perplexity,” Sep 2025
• Apple / Google joint statement on Gemini powering Apple Foundation Models, Jan 12, 2026; WWDC26 Siri AI confirmation, Jun 8, 2026
• TechCrunch, “Apple opens its new Siri AI to everyone with the iOS 27 public beta,” Jul 14, 2026