Google this week announced a feature for Chrome's AI Mode that media analyst Thomas Baekdal says revives one of the web's most contested practices from 20 years ago - but with a critical difference: this time, publishers have no technical way to block it.

The announcement, which Baekdal documented on LinkedIn on April 18, 2026, describes how Google's AI Mode in Chrome now opens publisher websites embedded directly inside the AI interface rather than in a separate tab or window. According to Baekdal, a media analyst and founder at Baekdal Media, the feature is functionally equivalent to the iframe embedding that publishers fought - and won against - in the early 2000s.

What iframes were, and why the web rejected them

For those unfamiliar with the history: in the early 2000s, platforms widely experimented with embedding third-party websites inside their own pages using HTML iframes. A site could load any other site inside a frame, surrounding it with their own interface, branding, and navigation. Publishers saw this as an appropriation of their content and design, and they pushed back. A practice called "framekilling" emerged, where publishers deployed JavaScript that would detect iframe embedding and force the browser to break out of the frame, loading the publisher's page as the top-level window.

The framekilling era did not last long in its original form. The underlying need for a proper technical standard led Microsoft to introduce a browser header called X-Frame-Options in the late 2000s. The header accepts two primary directives: DENY, which prevents any framing of the page by any site, and SAMEORIGIN, which restricts framing to pages hosted on the same origin domain. Browsers adopted the header widely. Chrome adopted it too - as did Google for its own properties.

According to Baekdal's analysis, attempting to embed google.com inside another site today returns a block because Google's own infrastructure uses X-Frame-Options: SAMEORIGIN. The Content Security Policy specification later introduced the frame-ancestors directive, which serves the same purpose with additional granularity. frame-ancestors 'self' instructs browsers to permit framing only from the same origin. Google deploys this directive as well.

The technical contradiction at the center of the announcement

This is where Baekdal's observation becomes technically pointed. In Google's own demonstration of AI Mode, the company shows sharkninja.com loaded inside the Chrome AI interface. According to Baekdal, Sharkninja's site carries both:

  • content-security-policy: frame-ancestors 'self'
  • x-frame-options: SAMEORIGIN

These headers explicitly instruct any conforming browser not to embed that page inside a third-party origin. They are not suggestions. They are security directives that browser vendors agreed to implement as a protection mechanism against clickjacking, phishing, surveillance, and unauthorized embedding. According to Baekdal, "This explicitly tells the browser 'do not embed this page' ... and yet, in Chrome when using Google AI mode, Google now embeds their site into their AI page."

The implication is significant: Chrome, which Google develops, is overriding security headers that Chrome itself is supposed to enforce. Other browsers - Firefox, Safari, Edge - enforce these headers as specified. For Chrome users on AI Mode, those headers appear to be selectively ignored when the AI interface is active.

Baekdal also disclosed his own situation: "On my site, I also have 'x-frame-options: SAMEORIGIN', which means that, as a publisher, I have also declared that I do not allow any third party to embed my site into theirs ... which Google's AI mode website in Chrome will completely ignore and just do anyway."

Google's own history of blocking this behavior

Baekdal traces the history with specificity. According to his analysis, Google began blocking iframe embedding of its own services in the early 2000s. The company then adopted the X-Frame-Options header after Microsoft introduced it, using it actively to protect google.com and its associated services from being embedded by third parties. For more than two decades, Google has operated under the technical and normative assumption that embedding another site inside yours without consent is unacceptable - a position it encoded into its own infrastructure.

The April 18 announcement represents a departure from that position. According to Baekdal's count, "For 20 years Google has been blocking what it today announced it will do to every other site online directly in Chrome." That the reversal is implemented inside Google's own browser - giving it scope over all Chrome users regardless of the publisher's stated preferences - is what distinguishes this from a standard API or product policy change.

Side-by-side, not tabs

The April 16 update to AI Mode in Chrome, reported by PPC Land, introduced a split-screen behavior on Chrome desktop. When a user clicks a link while using AI Mode, the publisher's page loads in a panel alongside the AI interface rather than opening in a new tab. According to the announcement, "when you're using AI Mode on Chrome desktop, clicking a link opens the webpage side-by-side with AI Mode. This makes it much easier to visit relevant websites, compare details and ask follow-up questions while still maintaining the context of your search."

The AI Mode interface remains persistent and visible. The publisher occupies a portion of the screen. According to PPC Land's coverage of the April 16 announcement, Google's AI can then use context from the open publisher page - combined with broader web data - to answer follow-up questions in real time.

Structurally, this resembles Google Sidewiki, a 2009 browser toolbar feature that allowed users to annotate web pages from within a Google-controlled sidebar. Sidewiki was discontinued in 2011 partly because publishers objected to Google inserting a persistent interface layer alongside their content. The April 18 iteration is technically different - it is a browser-native feature rather than a toolbar extension - but the structural dynamic is comparable.

Accessibility, security, and competition concerns

Commenters on Baekdal's LinkedIn post raised several categories of concern beyond the headline issue.

On security: embedding is commonly blocked for reasons that extend beyond publisher preference. Rose Newell, described in the LinkedIn thread as working in content, code, and strategy, wrote that "Embedding is often banned for many, many reasons - particularly security, plagiarism, phishing, and performance. By embedding, Google has a means to control everything - and monitor everything, including how you interact with those websites." The concern here is that when a page loads inside a Google-controlled interface, Google potentially has visibility into user interactions with that page at a granularity that would not otherwise be available.

On accessibility: Newell also raised the question of whether embedding may "override certain accessibility features, or confuse various browsing behaviours." Assistive technologies often rely on expected browser contexts and DOM structures. Loading a publisher page inside a non-standard frame within a proprietary AI interface introduces unpredictable interactions with screen readers, keyboard navigation, and other accessibility tooling.

On competition: If Chrome enforces the override for Google's own AI interface but not for competing browsers or AI services, the result is an asymmetry that benefits Google's product exclusively. Newell asked: "They have made it so Google in Chrome overrides those protections, so will other browsers and search engines try to follow suit? Will we normalise ignoring the original developer's intent?" The question of whether this constitutes an abuse of browser market position - Chrome held approximately 65% global browser market share as of late 2025 - is one that regulators in Europe and the United States have been examining in adjacent contexts.

The publisher traffic context

This development arrives against a backdrop of sustained tension between Google's AI search products and the publisher ecosystem. According to PPC Land, research from Ahrefs published on April 17, 2025, analyzed 300,000 keywords and found that AI Overviews reduced organic clicks to top-ranking websites by 34.5%. A Semrush study from June 9, 2025, found that while AI search visitors convert at 4.4 times the rate of traditional organic visitors, overall traffic volumes have declined for many publishers.

The IAB Tech Lab framework released June 4, 2025, estimated that AI-driven search summaries reduce publisher traffic by 20 to 60 percent on average, with niche sites experiencing losses of up to 90 percent. The organization placed annual ad revenue losses for publishers at approximately $2 billion.

Publishers have not been passive. Over 80 media executives gathered in New York during the week of July 30, 2025, under the IAB Tech Lab banner to address what many described as an existential threat to digital publishing. The meeting included representatives from Google and Meta but was notably absent of the AI companies - OpenAI, Anthropic, and Perplexity - that have been most directly criticized for content scraping.

The April 18 announcement adds a new dimension to this dispute. Prior concerns centered on AI systems consuming publisher content to generate responses without sending traffic back. The embedding behavior raises a different question: what is the meaningful distinction between a user visiting a publisher's site and a user accessing that same content through a Google-controlled interface wrapped around it? If Google's AI can observe, process, and respond to content on the embedded publisher page in real time, the question of who is serving that content - and who captures its value - becomes more complicated.

What publishers can do - and cannot do

According to Baekdal's analysis, there is currently no technical mechanism publishers can use to block this behavior. The standard tools - X-Frame-Options, content-security-policy: frame-ancestors - are the ones that Chrome is reportedly ignoring when AI Mode is active. JavaScript framekilling techniques require that the page's JavaScript executes in a context where it can detect and respond to the frame. If Chrome's AI Mode implementation suppresses or delays that detection, those techniques would also fail.

This contrasts sharply with the situation for other AI-related content access challenges. Publishers can set robots.txt rules to block AI crawlers, use Web Application Firewalls to filter bot traffic, and deploy nosnippet meta directives to prevent content from appearing in AI Overviews or AI Mode responses. None of those mechanisms address real-time embedding of live page content inside a browser interface. The IAB Europe framework published in September 2025 identified three primary control mechanisms for publishers managing AI content access: content access rules pages, JSON-based content metadata, and llms.txt files. None of those address this use case either.

A user agent problem

One commenter on Baekdal's post - William Waites, identified as working on trustworthy AI agent infrastructure at the University of Edinburgh - drew a line to a different piece of web history. The User-Agent HTTP header, sent by browsers to identify themselves to servers, derives its name from the concept of a browser as an agent acting on behalf of its user. Waites observed that the current AI Mode implementation "does not work for you, it works for Google." The concern is that an agent nominally acting for the user is actually structured to serve the platform's interests, with user benefit as a secondary effect.

This framing connects the embedding question to a broader architecture question about who controls the browser and for whose benefit. Chrome's implementation of AI Mode sits at the intersection of browser, search engine, and AI platform - three roles that were historically separate and are now unified in a single Google product.

What Google has said

Google's official announcement, linked in Baekdal's post, describes the feature in terms of user benefit: keeping users focused on tasks while exploring relevant web pages. The company has consistently maintained, including in statements to PPC Land, that its AI features increase the breadth of sites receiving traffic. CEO Sundar Pichai stated in a May 28, 2025 interview that "AI mode is going to have sources and you know, we're very committed as a direction, as a product direction, part of why people come to Google is to experience that breadth of the web."

Google has not, as of the date of this publication, responded to the specific question of whether Chrome's AI Mode selectively ignores X-Frame-Options and content-security-policy: frame-ancestors directives.

Timeline

Summary

Who: Thomas Baekdal, media analyst and founder at Baekdal Media, documented the behavior in a LinkedIn post on April 18, 2026. The feature affects all publishers whose sites can be accessed via Chrome's AI Mode, currently limited to US users.

What: Google's AI Mode in Chrome embeds publisher websites inside its own interface while ignoring X-Frame-Options: SAMEORIGIN and content-security-policy: frame-ancestors 'self' headers - the same security directives that Google uses to prevent embedding of its own properties, and that Chrome itself is designed to enforce.

When: The announcement and Baekdal's analysis were published on April 18, 2026. The underlying side-by-side feature was introduced in the April 16, 2026 AI Mode update.

Where: The behavior affects Chrome desktop users in the United States, where AI Mode's side-by-side view is currently available. No timeline for international expansion has been announced.

Why: The significance for publishers and the marketing community is that no existing technical mechanism - including the browser security headers specifically designed to prevent unauthorized embedding - can block this behavior when it originates from Chrome's own AI interface. Publishers have deployed these headers for 20 years as a baseline protection against framing, surveillance through embedded interaction data, and loss of interface control. The AI Mode implementation bypasses all of them.

Share this article
The link has been copied!