Your Hosting Rules Are Now Part of Your AI Marketing Strategy

A campaign team can spend days reviewing an offer, refining an email and shortening an SMS, then leave the rules governing access to the destination page entirely to its hosting provider. That division of labour deserves another look when an AI assistant may visit the page on a customer's behalf.

The question is not whether every automated visitor should be welcomed. It is whether the business has deliberately chosen which visits it wants, and whether its website actually permits them. I would now treat that choice as part of campaign planning, rather than an obscure setting to revisit after something breaks.

The hosting layer is making commercial decisions

In its 30 September 2026 account of the agentic web, Cloudflare highlighted separate controls for Search, Agent and Training traffic, alongside tools for identifying visitors and charging for certain uses. Its Pay Per Use and Monetization Gateway offerings launched as betas. They are not evidence that an ordinary campaign landing page should become a paid endpoint.

The more immediate point for marketers is the separation of purposes. An assistant checking an offer for a customer is doing a different job from a crawler collecting material for model training. A business can reasonably want one interaction and decline the other. Cloudflare's documentation defines Agent traffic as real-time activity on a person's behalf, including chat fetch bots and browser-use agents.

That makes the old conversation about whether to block bots too crude. The decision needs to begin with the business's intended relationship with that visitor, not just the fact that software is making the request.

A landing page and a publisher may want different things

Consider a hypothetical retailer sending an email about a weekend offer. A recipient asks an assistant to check delivery terms before deciding whether to buy. I would want the public offer and its conditions to be accessible to an appropriate assistant, while keeping account information and purchase actions behind their existing controls.

An advertising-funded publisher may make a different judgement about automated consumption of its articles. Cloudflare's 15 September release describes different recommended configurations for newly onboarded domains depending on advertising monetisation. Those recommendations are not a universal block on every existing website.

The same release distinguishes its Disallow AI Training preference from a hard block on mixed-use crawlers. It also describes operator commitments and capabilities still being developed. Teams should not turn that announcement into a promise that every operator already enforces every preference in the same way.

My conclusion is narrower: hosting defaults express assumptions about a business model. Marketing should know whether those assumptions fit the page it is promoting. Buying advertising to bring people to an offer is not the same as earning money by displaying advertising on that page.

Review access without weakening protection

I would not respond by disabling bot protection or opening every route to automation. A useful review should separate public information from actions and private data.

Start with a short statement of intent: recognised customer-directed assistants may read these public campaign pages; they may not bypass authentication, retrieve personal records or carry out consequential actions without the required permission. The exact implementation belongs with the people responsible for hosting and security. The commercial intent belongs with the campaign owner too.

For an email or SMS programme, I would ask the team to review three destinations: the advertised offer, the page explaining its conditions, and the next step a customer is expected to take. Decide what an assistant should be able to learn at each stage. A visitor that can read a headline but cannot reach the delivery exclusions has not completed a useful evaluation.

This review is about access, not a licence to collect more customer data. An assistant's ability to read public information should not be mistaken for permission to enrol someone in a mailing list or submit their details.

Test the journey, not just the home page

My proposed campaign check would use an actual supported assistant, where available, alongside an ordinary human browser. Ask the assistant to inspect the exact public destination and report the offer, expiry and relevant restrictions. Compare its answer with the approved page, then have the hosting team inspect the corresponding requests and any refusals.

If it fails, distinguish an access refusal from a reading error or outdated information. Those need different remedies. A successful visit to the home page is not proof that a campaign-specific route works, and a confident answer is not proof that the assistant fetched the current page.

I would also avoid treating a request carrying a copied bot name as a definitive test of a recognised service. The hosting team's evidence should establish what actually visited and how it was handled, rather than rely only on what a request claimed to be.

Keep the result modest: this assistant could read this page on this date under these conditions. That is useful operational evidence. It is not a guarantee of discovery, recommendation or increased sales across AI systems.

Give the decision an owner

For the next campaign, I would add one item to the launch checklist: has the hosting owner confirmed that the intended automated visitors can reach the public destination without weakening protections elsewhere? Record the answer alongside the offer approval and give someone responsibility for checking it again after a relevant hosting change.

The commercial measure should remain the quality of the customer journey and its outcomes, not a rising count of automated requests. More crawling can be activity without value. A blocked visit can be sensible protection or an unintended obstacle; the business needs enough context to tell the difference.

AI marketing is often discussed as a contest over who can generate better content. This is a less glamorous decision: who is allowed to read the content when a customer asks for help? A good campaign deserves an intentional answer at the hosting layer, not merely an attractive page behind whatever defaults happened to be selected.