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

Google Answers Why Some SEOs Split Their Sitemap Into Multiple Files via @sejournal, @martinibuster

Google’s John Mueller answered a question about why some websites use multiple XML sitemaps instead of a single file. His answer suggests that what looks like unnecessary complexity may come from reasons that are not immediately obvious.

The question came from an SEO trying to understand why managing multiple sitemap files would be preferred over keeping everything in one place.

Question About Using Multiple Sitemaps

The SEO framed the issue as a matter of efficiency, questioning why anyone would choose to increase the number of files they have to manage.

They asked:

“Can I ask a silly question, what’s the advantage of multiple site maps? It seems like your going from 1 file to manage to X files to manage.

Why the extra work? Why not just have 1 file?”

It’s a good question, avoiding extra work is always a good idea in SEO, especially if someone has a relatively small website, it makes sense to have just one sitemap but as Google’s Mueller explains, there may be good reasons to split a sitemap into multiple files.

Mueller Explains Why Multiple Sitemaps Are Used

Mueller responded by listing several reasons why multiple sitemap files are used, including both practical and less intentional causes.

He responded:

“Some reasons I’ve seen:

• want to track different kinds of urls in groups (“product detail page sitemap” vs “product category sitemap” — which you can kinda do with the page indexing report)
• split by freshness (evergreen content in a separate sitemap file – theoretically a search engine might not need to check the “old” sitemap as often; I don’t know if this actually happens though)
• proactively split (so that you don’t get to 50k and have to urgently figure out how to change your setup)
• hreflang sitemaps (can take a ton of space, so the 50k URLs could make the files too large)
• my computer did it, I don’t know why”

Mueller’s answer shows that sitemaps can be used in creative ways that serve a purpose. Something I’ve heard from enterprise level SEOs is that they find that keeping a sitemap to well under 50k lines ensures better indexing.

Takeaways

Mueller’s answer shows that sometimes keeping things “simple” isn’t always the best strategy. It might make sense apply organization to the sitemaps appears to be unnecessary complexity is often the result of practical constraints, evolving site structures, or automated systems rather than deliberate optimization.

• Multiple sitemaps can be used to group different types of content
• They help avoid hitting technical limits like the 50,000 URL cap
• Some implementations are based on theory rather than confirmed behavior
• Not all sitemap structures are intentional or strategically planned

Featured Image by Shutterstock/Rachchanont Hemmawong