Google’s CEO Predicts Search Will Become An AI Agent Manager via @sejournal, @martinibuster

In a recent interview, Google’s CEO, Sundar Pichai, explained how search is changing in response to advances in AI. The discussion centered on a simple question: If AI can act, plan, and execute, then what role will search play in the future?

Information Queries May Become Agent AI Search

The interviewer asked whether search remains a product or becomes something else as AI systems begin handling tasks instead of returning results.

They asked:

“What do you view as a future of search? Is it a distribution mechanism? Is it a future product? Is it one of N ways people are going to interact with the world?”

Had Pichai been interviewed by members of the publishing and SEO community, his answer may have received some pushback. He answered that search does not get replaced, but continues to expand as new capabilities are introduced and user expectations change.

He said:

“I feel like in search, with every shift, you’re able to do more with it.

And we have to absorb those new capabilities and keep evolving the product frontier.

If it’s mobile, the product evolved pretty quickly, you’re getting out of a New York subway, you’re looking for web pages, you want to go somewhere, how do you find it? So you’re constantly shifting, people’s expectations shift, and you’re moving along.

If I fast forward, a lot of what are just information seeking queries will be agentic search. You will be completing tasks, you have many threads running.”

In the first example of a person coming out of a New York subway, yes, someone may search for a web page, but will Google show the user a web page or treat it like data by summarizing it?

The second example completely removes the user from search and inserts agents in the middle. That scenario implicitly treats web pages as data.

Will Search Exist In Ten Years?

Pichai was asked what the future of search will be like in ten years. His answer suggests that the future of search will involve many information-seeking queries being handled as tasks carried out by agentic AI systems. Furthermore, search will be more like an orchestration layer that sits between the user and AI agents.

The exact question he was asked is:

“Will search exist in ten years?”

Google’s CEO responded:

“It keeps evolving. Search would be an agent manager, right, in which you’re doing a lot of things.

I think in some ways, I use anti-gravity today, and you have a bunch of agents doing stuff.

And I can see search doing versions of those things, and you’re getting a bunch of stuff done.”

At this point, the interviewer tried to get Pichai to return to the question of the actual search paradigm, if that will exist in ten years. Pichai declined to expressly state whether the search paradigm will still exist.

He continued his answer:

“Today in AI mode in search, people do deep research queries. So that doesn’t quite fit the definition of what you’re saying. But kind of people adapted to that.

So I think people will do long-running tasks, can be asynchronous.”

What he described is a version of search that manages actions across multiple steps, where multiple processes can run at once instead of returning a single set of ranked results. And yet, it’s weirdly abstract because he’s talking about queries but fails to mention websites or web pages in that specific context.

What’s going on? His next answer brings it into sharper focus.

Who Is The Flea And Who Is The Dog?

The interviewer picked up on Pichai’s mention of adaptation, made an analogy to evolution, and then asked:

“It’s almost like, does that former version or paradigm eventually go away? And what was search becomes an agent and your future interface is an agent, and the search box in ten years or n years is no longer the–“

Pichai interrupted the interviewer to say that it’s no longer possible to look ahead five or ten years because the models are changing, what people do is rapidly changing, and given that pace, the only thing to do is to embrace it.

He explained:

“The form factor of devices are going to change. I/O is going to radically change. And so …I think you can paralyze yourself thinking ten years ahead. But we are fortunate to be in a moment where you can think a year ahead, and the curve is so steep. It’s exciting to just do that year ahead, right?

Whereas in the past, you may need to sit and envision five years out, unlike the models are going to be dramatically different in a year’s time.

…I think it’ll evolve, but it’s an expansionary moment. I think what a lot of people underestimate in these moments is, it feels so far from a zero-sum game to me, right? The value of what people are going to be able to do is also on some crazy curve, right?

I think the more you view it as a zero-sum game, it looks difficult. It can become a zero-sum game if you’re innovating or the product is not evolving.

But as long as you’re at the cutting edge of doing those things, and we’re doing both search and Gemini, and so they will overlap in certain ways. They will profoundly diverge in certain ways, right? And so I think it’s good to have both and embrace it.”

What Google’s CEO is doing is rejecting the possibility of becoming obsolescent by deliberately focusing on competitive agility and embracing uncertainty as a strategic advantage.

That might work for Google, but what about websites?

I think businesses also need to embrace competitive agility and get out of the mental attitude of fleas on the dog. And yet, online businesses, publishers, and the SEO community are not fleas because Google itself is the one feeding off the web’s content.

What About Websites?

The interview lasted for over an hour, and at no point did Pichai mention websites. He mentioned web pages twice, once as something to understand with technology and once in the example of a person emerging from a subway who is looking for a web page. In both of those instances, the context was not Google Search looking for or fetching a web page in response to a query.

Given that Google Search is used by billions of people every day, it’s a bit odd that websites aren’t mentioned at all by the CEO of the world’s most successful search engine.

Google Confirms March 2026 Core Update Is Complete via @sejournal, @MattGSouthern

Google’s March core update has finished rolling out, according to the Google Search Status Dashboard.

The dashboard updated at 6:12 AM PDT on April 8 with the completion note: “The rollout was complete as of April 8, 2026.” The update began on March 27 at 2:00 AM PT, making the total rollout 12 days.

That’s within Google’s original two-week estimate and faster than the December 2025 core update, which took 18 days.

What Google Said About This Update

Google called the March 2026 core update “a regular update designed to better surface relevant, satisfying content for searchers from all types of sites.”

The company didn’t publish a companion blog post or announce specific goals for this update. It also didn’t share new guidance with the completion notice.

Core updates involve broad changes to Google’s ranking systems. They aren’t targeted at specific types of content or policy violations. Pages can move up or down based on how the update reassesses quality across the web.

Three Updates In One Month

March was unusually active for Google’s ranking systems. The core update was the third confirmed update in roughly five weeks.

The February Discover core update finished rolling out on February 27 after 22 days. That was the first time Google publicly labeled a core update as Discover-only.

The March 2026 spam update rolled out and completed in under 20 hours on March 24-25. That was the shortest confirmed spam update in the dashboard’s history.

The core update followed two days later on March 27.

Roger Montti, writing for Search Engine Journal, noted that the spam-then-core sequencing may not have been a coincidence. He wrote that spam fighting is logically part of the broader quality reassessment in a core update, comparing it to “clearing the table” before recalibrating the core ranking signals.

How The Rollout Compared To Recent Core Updates

The March rollout was the second-shortest of the past five broad core updates.

Only the December 2024 update finished faster.

Why This Matters

The completed rollout means you can now compare pre-update and post-update performance in Search Console across a full window. Google recommends waiting at least one full week after completion before drawing conclusions from the data.

Your baseline period should be the weeks before March 27, compared against performance after April 8. Keep in mind that the March spam update completed on March 25, so any ranking changes between March 24-27 could be from either update.

A drop in rankings after a core update doesn’t mean your site violated a policy. Core updates reassess content quality across the web, and some pages move up while others move down.

Looking Ahead

Google will likely continue making smaller, unannounced core updates between the larger confirmed rollouts. The company updated its core updates documentation in December to say that smaller core updates happen on an ongoing basis.

Featured Image: Rohit-Tripathi/Shutterstock

Google Says It Can Handle Multiple URLs To The Same Content via @sejournal, @martinibuster

Google’s John Mueller answered a question about duplicate URLs appearing after a site structure change. His response offers clarity about how Google handles duplicate content and what actually influences indexing and ranking decisions.

Concern About Duplicate URLs And Ranking Impact

A site owner had changed the URL structure of their web pages then later discovered that older versions of those URLs were still accessible and appearing in Google Search Console.

The person asking the question on Reddit was concerned that requesting recrawls of the older URLs might confuse Google or lead to ranking issues.

They asked:

“I switched over themes a while back and did some redesign and at some point …I changed all my recipes urls by taking the /recipe/ part out of site.com/recipe/actualrecipe so it’s now just site.com/actualrecipe but there are urls that still work when you put the /recipe/ back in the url.

I went to GSC and panicked that a bunch of my recipes weren’t indexed due to a 5xx error (I think it was when my site was down for a few days).

Now I’ve requested a bunch of them already to be recrawled, but realizing maybe google was ignoring them for a reason, like it didn’t want the duplicates.

Are my recrawl requests for /recipe/ urls going to confuse google who might penalize my ranking for the duplicates?”

The question reflects a reasonable concern that duplicate URLs and content might negatively affect rankings, especially when the error is surfaced through the search console indexing reports.

Google Is Able To Handle Duplicate URLs

Google’s John Mueller answered the question by explaining that multiple URLs pointing to the same content do not trigger a penalty or loss of search visibility. He also noted that this kind of duplication is common across the web, implying that Google’s systems are experienced with handling this kind of problem.

He explained:

“It’s fine, but you’re making it harder on yourself (Google will pick one to keep, but you might have preferences).

There’s no penalty or ranking demotion if you have multiple URLs going to the same content, almost all sites have it in variations. A lot of technical SEO is basically search-engine whispering, being consistent with hints, and monitoring to see that they get picked up.”

What Mueller is referring to is Google’s ability to canonicalize a single URL as the one that’s representative of the various similar URLs. As Mueller said, multiple URLs for essentially the same content is a frequent issue on the web.

Google’s documentation lists five reasons duplicate content happens:

1. “Region variants: for example, a piece of content for the USA and the UK, accessible from different URLs, but essentially the same content in the same language
2. Device variants: for example, a page with both a mobile and a desktop version
3. Protocol variants: for example, the HTTP and HTTPS versions of a site
4. Site functions: for example, the results of sorting and filtering functions of a category page
5. Accidental variants: for example, the demo version of the site is accidentally left accessible to crawlers”

The point is that duplicate content is something that happens often on the the web and is something that Google is able to handles.

Technical SEO Signals

Mueller said Google will pick one URL to keep, but added that the site owner might have preferences. That means Google will canonicalize the duplicates on its own, but the site owner or SEO can still signal which URL is the best choice (the canonical one) for ranking in the search results.

That is where technical SEO comes in. Internal linking, redirects, the proper use of rel=”canonical”, sitemap consistency, and consistency in 301 redirects all work as hints that help Google identify on the version you actually want indexed.

The Real Problem Is Mixed Signals

Mueller’s remark about making it harder on yourself was about the site owner/SEO spending time requesting URLs to be recrawled and noting that Google will figure it out on its own. But then he also referenced preferences, which alluded to all the signals I previously mentioned, in particular the rel=”canonical”.

Technical SEO Is Often About Reinforcing Preferences

Mueller’s description of technical SEO as “search-engine whispering” is useful because it captures how much of SEO involves reinforcing your preferences for what URLs are crawled, which content is chosen to rank, and indicating which pages of a website are the most important. Google may still choose a canonical on its own, but consistent signals increase the chance that it chooses the version the site owner wants.

That makes this a good example of what SEO is all about: Making it easy for Google to crawl, index, and understand the content. That’s really the essence of SEO. It is about being clear and consistent in the content, URLs, internal linking, overall site navigation, and even in showing the cleanest HTML, including semantic HTML (which makes it easier for Google to annotate a web page).

Semantic HTML can be used to clearly identify the main content of a web page. It can directly help Google zero in on what’s called the Centerpiece content, which is likely used for Google’s Centerpiece Annotation. The centerpiece annotation is a summary of the main topic of the web page.

Google’s canonicalization documentation explains:

“When Google indexes a page, it determines the primary content (or centerpiece) of each page. If Google finds multiple pages that seem to be the same or the primary content very similar, it chooses the page that, based on the factors (or signals) the indexing process collected, is objectively the most complete and useful for search users, and marks it as canonical. The canonical page will be crawled most regularly; duplicates are crawled less frequently in order to reduce the crawling load on sites.”

Technical SEO And Being Consistent

Stepping back to take a forest level view, duplicate URLs are really about a website not being consistent. Being consistent is not often seen as having to do with SEO but it actually is, on a general level. Every time I have created a new website I always had a plan for how to make it consistent, from the URLs to the topics, and also how to be able to expand that in a consistent manner as the website grows to cover more topics, to build that in.

Takeaways

• Multiple URLs to the same content do not cause a penalty or ranking demotion
• Google will usually pick one version to keep
• Site owners can influence that choice through consistent technical signals
• The real issue is mixed signals, not duplicate content itself
• Technical SEO often comes down to reinforcing clear preferences and monitoring whether Google picks them up
• The forest-level view of SEO can be seen as being consistent

Featured Image by Shutterstock/Andrey_Kuzmin

Google Explains Why It Doesn’t Matter That Websites Are Getting Larger via @sejournal, @martinibuster

A recent podcast by Google called attention to the fact that websites are getting larger than ever before. Google’s Gary Illyes and Martin Splitt explained that the idea that websites are getting “larger” is a bad thing is not necessarily true. The takeaway for publishers and SEOs is that Page Weight is not a trustworthy metric because the cause of the “excess” weight might very well be something useful.

Page Size Depends On What ‘s Being Measured

Google’s Martin Splitt explained that what many people think of as page size depends on what is being measured.

• Is it measured by just the HTML?
• Or are you talking about total page size, including images, CSS, and JavaScript?

It’s an important distinction. For example, many SEOs were freaked out when they heard that Googlebot was limiting their page crawl to just 2 megabytes of HTML per page. To put that into perspective, two megabytes of HTML equals about two million characters (letters, numbers, and symbols). That’s the equivalent of one HTML page with the same number of letters as two Harry Potter books.

But when you include CSS, images, and JavaScript along with the HTML, now we’re having a different conversation that’s related to page speed for users, not for the Googlebot crawler.

Martin discussed an article on HTTPArchive’s Web Almanac, which is a roundup of website trends. The article appeared to be mixing up different kinds of page weight, and that makes it confusing because there are at least two versions of page weight.

He noted:

“See that’s where I’m not so clear about their definition of page weight.

…they have a paragraph where they are trying to like explain what they mean by page weight. …I don’t understand the differences in what these things are. So they say page weight (also called page size) is the total volume of data measured in kilobytes or megabytes that a user must download to view a specific page. In my book that includes images and whatnot because I have to download that to see.

And that’s why I was surprised to hear that in 2015 that was 845 kilobytes. That to me was surprising. …Because I would have assumed that with images it would be more than 800 kilobytes.

… In July 2025, the same median page is now 2.3 megabytes.”

Data Gets Compressed

But that is only one way to understand page size. Another way to consider page size is by focusing on what is transferred over the network, which can be smaller due to compression. Compression is an algorithm on the server side that minimizes the size of the file that is sent from the server and downloaded by the browser. Most servers use a compression algorithm called Brotli.

Martin Splitt explains:

“I ask this question publicly that different people had very different notions of how they understood page size. Depending on the layer you are looking at, it gets confusing as well
because there’s also compression.

…So some people are like, ah, but this website downloads 10 megabytes onto my disk.

And I’m like, yes. …but maybe if you look at what actually goes over the wire, you might find that this is five or six megabytes, not the whole 10 megabytes. Because you can compress things on the network level and then you decompress them on the client side level…”

Technically, the page size in Martin’s example is actually five or six megabytes because of compression, and it’s able to download faster. But on the user’s side, that five or six megabytes gets decompressed, and it turns back into ten megabytes, which occupies that much space on a user’s phone, desktop, or wherever.

And that introduces an ambiguity. Is your web page ten megabytes or five megabytes?

That illustrates a wider problem: different people are talking about different things when they talk about page size.

Even widely used definitions don’t fully resolve the ambiguity. Page weight is described as “the total volume of data measured in kilobytes or megabytes that a user must download,” but as the discussion makes clear, there is no one clear definition.

Martin asserts:

“When you ask people what they think, if this is big or not, you start getting very different answers depending on how they think about page size. And there is no one true definition of it.”

What About Ratio Of Markup To Content?

One of the most interesting distinctions made in the podcast is that a large page is not necessarily inefficient. For example, a 15 MB HTML document is considered acceptable because “pretty much most of these 15 megabytes are actually useful content.” The size reflects the value being delivered.

By contrast, what if the ratio of content to markup were the other way around, where there was a little bit of content but the overwhelming amount of the page weight was markup.

Martin discussed the ratio example:

“…what if the markup is the only overhead? And I mean like what do you mean? It’s like, well, you know, if it’s like five megabytes but it’s only very little content, is that bad? Is that worse as in this case, the 15 megabytes.

And I’m like, that’s tricky because then we come into this weird territory of the ratio between content and markup. Yeah.

And I said, well, but what if a lot of it is markup that is metadata for some third party tool or for some service or for regulatory reasons or licensing reasons or whatever. Then that’s useful content, but not necessarily for the end user, but you still kind of have to have it.

It would be weird to say that that is worse than the page where the weight is mostly content.”

What Martin is doing here is shifting the idea of page weight away from raw size toward what the data actually represents.

Why Pages Include Data Users Never See

A major contributor to page weight is content that users never see.

Gary Illyes points to structured data as an example of content that is specifically meant for machines and not for users. While it can be useful for search engines, it also adds to the overall size of the page. If a publisher adds a lot of structured data to their page in order to take advantage of all the different options that are available, that’s going to add to the page size even though the user will never see it.

This calls attention to a structural reality of the web: pages are not just built for human readers. They are also built for search engines, tools, AI agents, and other systems, all of which add their own requirements to the weight of a web page.

When Overhead Is Justified

Not all non-user-facing content is unnecessary.

Martin talked about how markup may include “metadata” or a tool, regulatory, or licensing purpose, creating a kind of gray area. Even if the additional data does not improve the user experience directly, it does serve a purpose, including helping the user find the page through a search engine.

The point that Martin was getting at is that these considerations of page weight complicate attempts to label page weight as good if it is under this threshold or bad if the page weight exceeds it.

Why Separating Content and Metadata Doesn’t Work

One possible solution that Gary Illyes discussed is separating human-facing content from machine-facing data. While Gary didn’t specifically mention the LLMs.txt proposal, what he discussed kind of resembles it in that it serves content to a machine minus all the other overhead that goes with the user-facing content.

What he actually discussed was a way to separate all of the machine-facing data from what the user will download, thus, in theory, making the user’s version of a web page smaller.

Gary quickly dismisses that idea as “utopic” because there will always be hordes of spammers who will find a way to take advantage of that.

He explained:

“But then unfortunately this is an utopic thing. Because not everyone on the internet is playing nice.

We know how much spam we have to deal with. On our blog we say somewhere that we catch like 40 billion URLs per day that’s spam or some insane number, I don’t remember exactly, but it’s some insane number and definitely billions. That will just exacerbate the amount of spam that search engines receive and other machines receive maybe like I would bet $1 and 5 cents that will actually increase the amount of spam that search engines and LLMs and others ingest.”

Gary also said that Google’s experience is that, historically, when you have separate kinds of content, there will always be differences between the two kinds. He used the example of when websites had mobile and desktop pages, where the two versions of content were generally different, which in turn caused issues for search and also for usability when a site ranks a web page for content on one version of a page, then sends the user to a different version of the page where that content does not exist.

Although he didn’t explicitly mention it, that explanation of Google’s experience may shed more light on why Google will not adopt LLMS.txt.

As a result, search engines have largely settled on a single-document model, even if it is inefficient.

Website Size vs Page Size Is the Real World

The discussion ultimately challenges the original concept of the problem, that heavy web pages are bad.

Gary observes:

“The first question is, are websites getting fat? I think this question is not even meaningful.

Because it does not matter in the context of a website if it’s fat. In the context of a single page, yes.

But in the context of a website, it really doesn’t matter.”

So now Gary and Martin change the focus to web pages that are getting heavier, a more meaningful way to look at the issue of how web pages and websites are evolving.

This moves the discussion from an abstract idea to something more measurable and actionable.

Heavier Pages Still Carry Real Costs

Even with faster connections and better infrastructure, larger pages still have consequences, and smaller weighted pages have positive benefits.

Martin explains:

“I think we are wasting a lot of resources. And I mean we, we had that in another episode where we said that we know that there are studies that show that websites that are faster have better retention and better conversion rates. Yeah. And speed is in part also based on size. Because the more data I ship, the longer it takes for the network to actually transfer that data and the longer it takes for the processor of whatever device you’re on to actually process it and display it to you.”

From a broader perspective, the issue is not just performance but efficiency. As Illyes puts it, “we are wasting a lot of resources.”

The web may be getting heavier, but the more important takeaway is why. Pages are carrying more than just user-facing content, and that design choice shapes both their size and their impact.

Featured Image by Shutterstock/May_Chanikran

Google’s Mueller On SEO Gurus Who Are “Clueless Imposters” via @sejournal, @martinibuster

A search marketing professional from India wrote a blog post about how she feels about seeing the word guru used within the SEO community in a way that’s different from its meaning in India. Several people, including Google’s John Mueller, agreed with her and shared how they felt when people self-identify as SEO gurus.

The Word Guru Is Misused

Preeti Gupta wrote a blog post titled, I don’t like how the word ‘Guru’ is misused in the SEO industry, in which she shared what the word guru actually means and how it’s misused in the SEO industry in a way that trivializes a word that in India holds special meaning.

She wrote that in India the word guru has a deep meaning and that they hold great respect for actual gurus.

Her blog post shared a Sanskrit mantra about it:

“The Guru is like Brahma (the creator). They create the desire for knowledge.
The Guru is like Vishnu (The preserver). They help the student keep and use the knowledge.
The Guru is like Maheshwara (Shiva, the Destroyer). They destroy ignorance and bad habits.
The Guru is the supreme reality itself, standing right before your eyes.
I bow and offer my respects to that great teacher.”

She then contrasted that profound meaning of the word guru with the trivialization of it within the context of self-described SEO gurus, who she regards as shady types who engage in unethical SEO practices. She said that it’s not her intention to tell people what words to use, but she did express the hope that people would use the word in the right context.

The phrase SEO guru is used in both contexts, as a derogatory phrase to paint someone as a false leader with naïve followers and also as someone who is highly regarded. However, I think an argument can be made that using that phrase for oneself is immodest, self-aggrandizing, and simply isn’t a good look.

AlexHarford-TechSEO responded to her post on Bluesky:

“It puts me off when I see an SEO self-describe themselves as a “Guru.” I’ve never come across anyone who does so who is a good and ethical SEO.

A lot of words are losing meaning in today’s world, though there can’t be many that were as special to you as Guru.”

Words are always in a state of change, and the way people speak not only changes from region to region but also from decade to decade. The meaning of words does change, especially when they jump continents and languages.

Self-Declared SEO Gurus

It was at this point that John Mueller responded to share what he thinks about self-described SEO gurus:

“To me, when someone self-declares themselves as an SEO guru, it’s an extremely obvious sign that they’re a clueless imposter. SEO is not belief-based, nobody knows everything, and it changes over time. You have to acknowledge that you were wrong at times, learn, and practice more.”

Mueller is right that nobody knows everything and that SEO changes over time, and for a long time many SEOs didn’t keep up with how Google ranks websites. The industry has largely shed that naivete, and yet nobody really agrees on what to do to rank better in search engines and AI search.

SEO Is A Belief System

Although I know there are some SEOs who firmly believe that SEO is a set of universally agreed upon practices and that that is all there is, unaware that the history of SEO is one of constant change. How SEO is practiced today is quite different from how it was practiced eight years ago. There is no set of practices to be agreed on except Google’s best practices, which are less about do this and you will rank better and more about do this and you may have a chance to rank better.

So yes, to a certain extent, SEO is a belief system and will continue to be a belief system so long as Google’s search ranking algorithms remain a black box algorithm that people can see what goes in and what comes out but not what happens in the middle. That part remains a mystery. So when you don’t know for sure that what you do will guarantee better rankings, the only thing left is to believe, hope, and even have faith that the rankings will happen. Faith, after all, is belief in something that does not provide definitive proof. You don’t need faith to believe in a fact, right?

And that last part, the mystery of what happens in the black box, is why nobody can really call themselves a guru in the sense of being all-knowing. Nobody outside of Google knows everything that’s going on within that part in the middle where the rankings “magic” happens.

Given all that, who can truly call themselves a guru in SEO?

Featured Image by Shutterstock/funstarts33