But at the same time, AI companies are breaking the web's fundamental economic model. This problem demands our attention.

The AI extraction problem

For 25 years, we built the Open Web on an implicit agreement: search engines could index our content because they sent users back to our websites. That model helped sustain blogs, news sites, and even Open Source projects.

AI companies broke that model. They train on our work and answer questions directly in their own interfaces, cutting creators out entirely. Anthropic's crawler reportedly makes 70,000 website requests for every single visitor it sends back. That is extraction, not exchange.

This is the Makers and Takers problem all over again.

The damage is real:

• Chegg, an online learning platform, filed an antitrust lawsuit against Google, claiming that AI-powered search answers have crushed their website traffic and revenue.
• Stack Overflow has seen a significant drop in daily active users and new questions (about 25-50%), as more developers turn to ChatGPT for faster answers.
• I recently spoke with a recipe blogger who is a solo entrepreneur. With fewer visitors, they're earning less from advertising. They poured their heart, craft, and sweat into creating a high-quality recipe website, but now they believe their small business won't survive.

None of this should surprise us. According to Similarweb, since Google launched "AI Overviews", the number of searches that result in no click-through has increased from 56% in May 2024 to 69% in May 2025, meaning users get their answers directly on the results page.

This "zero-click" phenomenon reinforces the shift I described in my 2015 post, "The Big Reverse of the Web". Ten years ago, I argued that the web was moving away from sending visitors out to independent sites and instead keeping them on centralized platforms, all in the name of providing a faster and more seamless user experience.

However, the picture isn't entirely negative. Some companies find that visitors from AI tools, while small in volume, convert at much higher rates. At Acquia, the company I co-founded, traffic from AI chatbots makes up less than 1 percent of total visitors but converts at over 6 percent, compared to typical rates of 2 to 3 percent. We are still relatively early in the AI adoption cycle, so time will tell how this trend evolves, how marketers adapt, and what new opportunities it might create.

Finding a new equilibrium

There is a reason this trend has taken hold: users love it. AI-generated answers provide instant, direct information without extra clicks. This makes traditional search engines look complicated by comparison.

But this improved user experience comes at a long-term cost. When value is extracted without supporting the websites and authors behind it, it threatens the sustainability of the content we all rely on.

I fully support improving the user experience. That should always come first. But it also needs to be balanced with fair support for creators and the Open Web.

We should design systems that share value more fairly among users, AI companies, and creators. We need a new equilibrium that sustains creative work, preserves the Open Web, and still delivers the seamless experiences users expect.

Some might worry it is already too late, since large AI companies have massive scraped datasets and can generate synthetic data to fill gaps. But I'm not so sure. The web will keep evolving for decades, and no model can stay truly relevant without fresh, high-quality content.

From voluntary rules to enforcement

We have robots.txt, a simple text file that tells crawlers which parts of a website they can access. But it's purely voluntary. Creative Commons launched CC Signals last week, allowing content creators to signal how AI can reuse their work. But both robots.txt and CC Signals are "social contracts" that are hard to enforce.

Today, Cloudflare announced that they will block AI crawlers by default. This change lets website owners decide whether to allow access and whether to negotiate compensation. Cloudflare handles 20% of all web traffic. When an AI crawler tries to access a website protected by Cloudflare, it must pass through Cloudflare's servers first. This allows Cloudflare to detect crawlers that ignore robots.txt directives and block them.

This marks a shift from purely voluntary signals to actual technical enforcement. Large sites could already afford their own infrastructure to detect and block crawlers or negotiate licensing deals directly. For example, Reddit signed a $60 million annual deal with Google to license its content for AI training.

However, most content creators, like you and me, can do neither.

Cloudflare's actions establish a crucial principle: AI training data has a price, and creators deserve to share in the value AI generates from their work.

The missing piece: content licensing marketplaces

Accessible enforcement infrastructure is step one, and Cloudflare now provides that. Step two would be a content licensing marketplace that helps broker deals between AI companies and content creators at any scale. This would move us from simply blocking to creating a fair economic exchange.

To the best of my knowledge, such marketplaces do not exist yet, but the building blocks are starting to emerge. Matthew Prince, CEO of Cloudflare, has hinted that Cloudflare may be working on building such a marketplace, and I think it is a great idea.

I don't know what that will look like, but I imagine something like Shutterstock for AI training data, combined with programmatic pricing like Google Ads. On Shutterstock, photographers upload images, set licensing terms, and earn money when companies license their photos. Google Ads automatically prices and places millions of ads without manual negotiations. A future content licensing marketplace could work in a similar way: creators would set licensing terms (like they do on Shutterstock), while automated systems manage pricing and transactions (as Google Ads does).

Today, only large platforms like Reddit can negotiate direct licensing deals with AI companies. A marketplace with programmatic pricing would make licensing accessible to creators of all sizes. Instead of relying on manual negotiations or being scraped for free, creators could opt into fair, programmatic licensing programs.

This would transform the dynamic from adversarial blocking to collaborative value creation. Creators get compensated. AI companies get legal, high-quality training data. Users benefit from better AI tools built on ethically sourced content.

Making the Open Web sustainable

We built the Open Web to democratize access to knowledge and online publishing. AI advances this mission of democratizing knowledge. But we also need to ensure the people who write, record, code, and share that knowledge aren't left behind.

The issue is not that AI exists. The problem is that we have not built economic systems to support the people and organizations that AI relies on. This affects independent bloggers, large media companies, and Open Source maintainers whose code and documentation train coding assistants.

Call me naive, but I believe AI companies want to work with content creators to solve this. Their challenge is that no scalable system exists to identify, contact, and pay millions of content creators.

Content creators lack tools to manage and monetize their rights. AI companies lack systems to discover and license content at scale. Cloudflare's move is a first step. The next step is building content licensing marketplaces that connect creators directly with AI companies.

The Open Web needs economic systems that sustain the people who create its content. There is a unique opportunity here: if content creators and AI companies build these systems together, we could create a stronger, more fair, and more resilient Web than we have had in 25 years. The jury is out on that, but one can dream.

Disclaimer: Acquia, my company, has a commercial relationship with Cloudflare, but this perspective reflects my long-standing views on sustainable web economics, not any recent briefings or partnerships.

Unlike third-party cookies, first-party cookies are restricted to the website you are on. They are often used to improve the user experience, such as keeping you logged in, remembering what is in your shopping cart, and more.

Of course, first-party cookies can also be used to track your activity, like with Google Analytics, but they can't be used to follow you beyond that site. While both types of cookies can be used to track users, third-party cookies are much more invasive and problematic.

In 2018, I made the decision to remove all tracking tools, including Google Analytics, from my personal site. My website aspires to the privacy of printed works. The anonymity of a book holds a unique charm, and I find joy in not knowing who visits my website.

That said, I have no issue with the use of first-party cookies, provided it's consensual and used to improve the user experience. I understand their importance for many organizations, especially in marketing.

Fortunately, the era of third-party cookies is coming to a close. Browsers like Safari and Firefox have already taken steps to limit third-party tracking. They still allow certain third-party cookies to ensure websites work properly. Two examples include:

1. E-commerce sites often rely on third-party cookies for integrating payment systems. Blocking these cookies could disrupt the payment process.
2. Complex digital platforms, like healthcare and government websites, sometimes use cross-site authentication to link departmental websites. Blocking these could prevent access to important services.

While Safari and Firefox have been limiting third-party cookies for some time, Google Chrome is lagging behind. Google only began phasing out third-party cookies in early 2024 (a few weeks ago), starting with just 1% of its users. Their plan is to expand this to all users by the end of 2024.

Google's strategy can be viewed in two ways:

1. Negatively, it could look like Google is delaying the phase-out because it profits from the advertising revenue these cookies generate.
2. Positively, Google is cautious in removing third-party cookies to avoid disrupting websites that rely on them for non-advertising purposes.

As a regular Chrome user, I didn't want to wait until the end of 2024. If you feel the same, you can block third-party cookies in Chrome now. Just head to Settings, select Privacy and Security and activate Block third-party cookies. Just beware, as some sites might stop working.

If you manage or develop websites, check they rely on third-party cookies. Use my HTTP Header Analyzer to check for SameSite=None attributes indicating third-party cookies, or test by disabling them in Chrome.

Because I don't have a compelling reason to track my site's visitors, I don't have to bother anyone with a "cookies consent" popup either. That is a nice bonus because the web is littered with those already. I like that dri.es is clutter-free.

This was all well and good until a couple of weeks ago, when I learned that when I embed a YouTube video in my blog posts, Google sends an HTTP cookie to track my site's visitors. Be damned!

After some research, I discovered that YouTube offers a privacy-enhanced way of embedding videos. Instead of linking to youtube.com, link to youtube-nocookie.com, and no data-collecting HTTP cookie will be sent. This is Google's way of providing GDPR-compliant YouTube videos.

<iframe width="640" height="360" src="https://www.youtube-nocookie.com/embed/video-id" frameborder="0"></iframe>

So I went ahead and updated all blog posts on dri.es to use youtube-nocookie.com.

In addition to improving privacy, this change also makes my site faster. I used https://webpagetest.org to benchmark a recent blog post with a YouTube video.

Before:

After:

We will not shy away from high-risk, high-reward projects because of short term earnings pressure. Some of our past bets have gone extraordinarily well, and others have not. Because we recognize the pursuit of such projects as the key to our long term success, we will continue to seek them out. For example, we would fund projects that have a 10% chance of earning a billion dollars over the long term. Do not be surprised if we place smaller bets in areas that seem very speculative or even strange when compared to our current businesses. Although we cannot quantify the specific level of risk we will undertake, as the ratio of reward to risk increases, we will accept projects further outside our current businesses, especially when the initial investment is small relative to the level of investment in our current businesses.

Think big and fail well – fail fast, fail often, and learn from your mistakes.

Capital expenditures, or CAPEX, is money used to purchase, upgrade, improve, or extend the life of long-term assets. Capital expenditures generally takes two forms: maintenance expenditure (money spent for normal upkeep and maintenance) and expansion expenditures (money used to buy assets to grow the business, or money used to buy assets to actually sell). This could include buying a building, upgrading computers, acquiring a business, or in the case of cloud infrastructure vendors, buying the hardware needed to invest in the growth of their cloud infrastructure.

Building this analysis on CAPEX spending is far from perfect, as it includes investments that are not directly related to scaling cloud infrastructure. For example, Google is building subsea cables to improve their internet speed, and Amazon is investing a lot in its package and shipping operations, including the build-out of its own cargo airline. These investments don't advance their cloud services businesses. Despite these inaccuracies, CAPEX is still a useful indicator for measuring the growth of their cloud infrastructure businesses, simply because these investments dwarf others.

The Platformonomics analysis prompted me to do a bit of research on my own.

The graph above shows the trailing twelve months (TTM) CAPEX spending for each of the five cloud vendors. CAPEX don't lie: cloud infrastructure services is clearly a three-player race. There are only three cloud infrastructure companies that are really growing: Amazon, Google (Alphabet) and Microsoft. Oracle and IBM are far behind and their spending is not enough to keep pace with Amazon, Microsoft or Google.

Amazon's growth in CAPEX is the most impressive. This becomes really clear when you look at the percentage growth:

Amazon's CAPEX has exploded over the past 10 years. In relative terms, it has grown more than all other companies' CAPEX combined.

The scale is hard to grasp

To put the significance of these investments in cloud services in perspective, in the last 12 months, Amazon and Alphabet's CAPEX is almost 10x the size of Coca-Cola's, a company whose products are available in every grocery store, gas station, and vending machine in every town and country in the world. More than 3% of all beverages consumed around the world are Coca-Cola products. In contrast, the amount of money cloud infrastructure vendors are investing in CAPEX is hard to grasp.

Disclaimers: As a public market investor, I'm long Amazon, Google and Microsoft. Also, Amazon is an investor in my company, Acquia.

The accepted students, their projects, and the mentors are listed on the official Drupal.org announcement. Congratulations to all successful applicants, and thanks to the Drupal Summer of Code organizers, the Drupal mentors, and last but not least, Google. The summer is of to a great start!

Google's Rich Snippets provide summary information to help users quickly identify the relevance of their search results. For example, if you search for a restaurant, rich snippets may include an average review score, a price range, or more. As users get more sophisticated at search, they'll ask Google increasingly complex questions. Rich Snippets allow Google to stay on top of that trend, and prevents losing users to competitors.

It is very hard for search engines to understand the structure and semantics of data embedded in an HTML page. To create these snippets, Google needs the help of hundreds of thousands of webmasters around the world, and by extension, content management systems like Drupal, Joomla!, and others. Specifically, Google is asking all of us to surface structured data to their crawlers by marking up our HTML with RDFa and Microformats. When Google announced Rich Snippets this week, they really announced support for RDFa and Microformats, and the semantic web in general. This is big.

Initially, Google's adoption of RDFa will disrupt the current approaches to Search Engine Optimization (SEO). With Google entering the RDFa game, the words "semantic markup" will get redefined. Every webmaster wanting to improve click-through rates, reduce bounce rates, and improve conversation rates, can no longer ignore RDFa or Microformats. Structured data is the new SEO.

As I've written before, search engines like Google and Yahoo! will provide the killer apps (e.g. vertical search engines) that the semantic web has been waiting for. Five years from now, we'll look back and say: "All it took was some incentive for the SEO industry." ...

Rich Snippets is a natural step in making search better. It provides a glimpse into the future of search, and tempts us with the possibilities of the semantic web. Right now, Google has a database of pages. If you read beneath the lines of their announcement, what Google is really asking is for us to help them in building giant specialized databases of all products, people, places and events in the world. This provides opportunities well beyond providing rich search snippets. We're turning the web into a giant database for Google (and others) to slice and dice as needed.

For example, it is easy to see that a database of all the job applications in the world, built by crawling hundreds of thousands of independent RDFa-enabled sites, will impact specialized job sites. Or how a database of all the product or movie reviews in the world could affect specialized review sites. It might seem scary at the surface, but it really isn't. On the web, scale and reach are more important than scarcity – you win by setting data free, not by holding it close to your chest.

For many of us in the Drupal community, Google's announcement couldn't be more timely. The Drupal community has been working on adding RDFa support to Drupal 7, and at this very moment, people from the community are gathering in Galway for a week long code sprint to get more RDFa support in Drupal 7 core. Once again, Drupal proves itself to be on the cutting edge, and is taking a leadership role in adopting semantic web technologies. As I said in my DrupalCon Boston keynote 1.5 years ago, I believe that Drupal can become a significant player in the development of the semantic web. It's bullish, and maybe even naive, but I couldn't be more excited about giving the semantic web snowball a small push.

The accepted students, their projects, and the mentors are listed on the official Drupal.org announcement. Congratulations to all successful applicants, and thanks to the Drupal Summer of Code organizers, the Drupal mentors, and last but not least, Google. Awesome!