# Cloudflare Pay Per Crawl: calculate potential revenue from paid crawler requests Estimate which automated requests could actually qualify for payment. Total bot requests alone are not paid demand or revenue. Published: 2026-11-01 Updated: 2026-11-02 Author: Staff Writers Publisher: Digital Publishing News Earlier version reviewed by Shaun Connell, Managing Editor Canonical: https://digitalpublishingnews.com/articles/cloudflare-pay-per-crawl/ ## Estimate requests that could qualify for payment A million crawler requests do not mean a million potential sales. Before planning revenue from paid crawler access, estimate how many requests would be eligible for payment and how many buyers would actually agree to pay. Cloudflare, a provider of website delivery and security services, announced Pay Per Crawl on July 1, 2025 as a mechanism for charging certain automated requests. That announcement establishes a proposed transaction mechanism. It does not establish current availability for your account, a market price for your content or demand from paying buyers. Source: https://blog.cloudflare.com/introducing-pay-per-crawl/ ## A million bot requests are not a million sales Use a request-to-cash model: eligible requests × participating paid share × price per paid request, then reconcile the result to settled payments. Historical traffic supplies only a starting volume; it does not reveal willingness to pay. Illustration: 1,000,000 monthly requests × 10% eligible × 5% paid participation × $0.01 = $50 gross. At 1% paid participation the same model produces $10. These are invented inputs, not Cloudflare prices or observed demand. Inputs needed for a request-to-receipts calculation Input | Evidence needed --- | --- Eligible volume | Requests to content covered by the available product. Paid participation | Requests from actual participating buyers. Price | The applicable price and charging rules. Realized receipts | Paid events reconciled to settlement. ## What would make a pilot worth running? At the illustrative one-cent price, $50 of monthly operating costs requires 5,000 paid requests just to break even before fees. With 100,000 eligible requests, that means 5% paid participation. At $100 of costs, the requirement doubles to 10,000 paid requests, or 10%. These are planning scenarios, not evidence that buyers will participate. Before a trial, obtain current account eligibility, charging rules and settlement terms. Record attempted, eligible, paid and settled requests separately, then compare collected income with staff time, service costs and any observed change in discovery. Set the spending limit from plausible receipts, not the largest bot-traffic number in a dashboard. ## Estimate the sales needed to justify a pilot Separate the monthly cost of running the pilot from the cost per paid request. Suppose the extra monitoring costs $100 a month and you keep one cent on each paid request after fees. You would need 10,000 paid requests to cover that operating cost. If your logs show a million automated requests, the model requires one percent of those requests to become paid at the assumed rate. This is a hypothetical hurdle, not a prediction about uptake. Decide before the pilot what counts as success. Capture paid receipts, any change in ordinary referral traffic, and staff time spent resolving crawler problems. Use the same time window for the figures. If the paid revenue looks attractive but ordinary referrals fell during the same period, investigate the policy and traffic change separately before calling the pilot a net gain. ## Decide what qualifies as revenue in a pilot Imagine a report shows 12,000 requests to pages configured for payment, but only 8,000 were actually paid at your assumed net rate of one cent. The publisher received $80 in this example. Reporting $120 would confuse eligible traffic with transactions. Keep a receipt or settlement record alongside the request log and report the window each covers. If operating costs are $100, that result falls $20 short before considering any change in referrals. Investigate whether there was too little paid demand, the terms differ from the modeled price, or the time window was incomplete. Those explanations lead to different next steps. Counting more automated traffic will not by itself establish that the missing revenue exists. AI production disclosure: https://digitalpublishingnews.com/how-we-use-ai/ ## Sources https://blog.cloudflare.com/introducing-pay-per-crawl/ Editorial status: AI-assisted revision; preceding edition reviewed by Shaun Connell. Current revision awaits review.