When Context Gets Lost: The Risk of Misreading Google’s Advice

In this episode of the International Web Effectiveness Podcast, Bill Hunt and Bill Scully explore the consequences of taking SEO guidance out of context, especially when it comes from headlines or misquoted responses from Google.

They focus on a recent debate around hreflang tags and 301 redirects, revealing how even small misunderstandings can derail complex site migrations and international SEO setups. This discussion also uncovers common pitfalls around structured data, AI-generated content, and the recurring SEO trap of confusing correlation with causation.

Whether you’re managing a global website or just trying to make smart SEO decisions, this episode offers practical insights to help you separate noise from real strategy.


https://spotifycreators-web.app.link/e/aF7FW4c8DSb

Key Takeaways

  • Context matters, especially when interpreting SEO recommendations.
  • Hreflang tags should always point to live (200 status) pages.
  • 301 redirects can disrupt hreflang reciprocity and reporting.
  • Google might figure it out, but that’s a risky assumption.
  • During migrations, precision in hreflang matters more than ever.
  • Structured data can improve visibility, but it’s not a direct ranking factor.
  • Critical thinking beats blind implementation every time.

Catch the Full Episode

Youtube: https://youtu.be/Qw9W5d5H_cs

Spotify: https://open.spotify.com/episode/4ERQojxBpCuuLWDhh526Z4?si=WTARQCD-T9iJ9TEUdn55Rw

Apple Podcast: https://podcasts.apple.com/us/podcast/when-context-gets-lost-the-risk-of-misreading/id1755789311?i=1000703907807


Show Note Links

Google: Hreflang Tags With 301 Redirects Are Probably Okay by Barry Schwartz:

⁠https://www.seroundtable.com/google-hreflang-301-redirects-39185.html⁠

Google Again Says Structured Data Does Not Make Your Site Rank Better by Barry Schwartz:

⁠https://www.seroundtable.com/google-structured-data-ranking-39232.html ⁠

When Context Gets Lost: The Risk of Misreading Google’s Advice by Bill Hunt: ⁠

https://internationalwebmastery.com/blog/when-context-gets-lost-the-risk-of-misreading-googles-advice/⁠

Google SOTR Podcast Recap – Duplicate Content by Bill Hunt:

⁠https://internationalwebmastery.com/blog/google-sotr-podcast-recap-duplicate-content/⁠

When a Simple Change Sparks Complex Assumptions: The Danger of Misreading Google’s Signals by Bill Hunt

⁠https://internationalwebmastery.com/blog/when-a-simple-change-sparks-complex-assumptions-the-danger-of-misreading-googles-signals/ ⁠

Understanding & Fixing Common Hreflang Errors Course:

⁠https://learn.internationalwebmastery.com/courses/understanding-fixing-common-hreflang-errors


Transcript

Bill Scully (00:02)
Welcome to episode 32 of the International Web Effectiveness Podcast, where Bill Hunt and I, Bill Scully, focus on the strategies and techniques necessary to improve your web presence and manage your global websites. In episode 31, we reviewed hallucinations in AI agents and how to deal with them. In this episode, we’re going to discuss the problems that arise when people lose the context of a statement or recommendation from Google or industry experts — and the risks of misinterpreting advice. Too often, claims get made on social media, and people take them at face value. We can’t keep doing that.

So, Bill, you actually created a rant about this on the International Web Mastery site. Want to tell us about it?

Bill Hunt (00:58)
Sure — I always enjoy a good rant. Funny enough, I saw an email early Monday morning from Barry Schwartz at Search Engine Roundtable about hreflang and 301 redirects. It caught my attention because a search marketer had asked John Mueller on Mastodon whether hreflang tags need to point to 200-status pages.

Bill Scully (01:01)
[Laughs]

Bill Hunt (01:27)
The question was a bit more nuanced than that, and we’ve included links to it in the show notes. Barry’s article was titled: Google: hreflang Tags with 301 Redirects Are Probably OK.

As soon as I read that headline — without even opening the article — I messaged you and said, “Bill, this is going to ruin my week.” I tried not to let it get to me… but it was like a car wreck — you have to look. So I read it.

Using a bit of critical thinking, I took John’s post at face value. His exact quote was:

“If they’re 301, it’s probably OK, but it sounds like it might be worth figuring out how to automate it so you don’t need to manually track and tweak these. Clean links make tracking with tools easier and reduce chances of miscanonicalization. Not a ranking issue, but tracking is challenging.”

Now, depending on how you interpret that, it sounds like it’s “probably okay.” But if you go back to Matt’s actual post, he asked: “Hey, back in 2018, you tweeted that hreflang tags need to point to 200-status pages. Is that still relevant today?”

After a global migration, his implementation was hit-or-miss — some hreflang links pointed to pages that 301-redirected to new URLs. So he asked whether those were considered broken, or if Google could handle it.

Whenever I see “Can Google handle it?” my immediate thought is — we shouldn’t be relying on that. And to be clear, I’m not criticizing Matt here. But back in 2018, Google said 200-status pages were ideal for hreflang. Seven years later — yes, it’s still ideal.

John was responding to a specific case: “Hey, our implementation isn’t perfect. Is that okay?” I really wish Google had just said, “No — those are broken. We will not fix it. Move on.”

Instead, John gave a general answer to a nuanced question. I think he was trying to address the reporting issue — that these show up as “naughty” in reports. So my interpretation, based on critical thinking, was: if most hreflang annotations are okay, then it’s probably not a huge issue. It’s more about how it appears in reporting than whether it impacts indexing.

Bill Scully (04:39)
Right — exactly.

Bill Hunt (04:59)
So rather than playing whack-a-mole to fix every instance, it’s probably okay if a few are off.

Bill Scully (05:08)
And who’s to say John wasn’t talking about hreflang in general? Like, maybe you have a few mismatches, but there are probably other signals that help compensate, especially if the rest of your site has hreflang implemented properly.

Bill Hunt (05:33)
Right…

Bill Scully (05:37)
Let me have it — go ahead.

Bill Hunt (05:37)
Yes. No.

Let me jump to why this matters. The number one requirement in hreflang implementation is reciprocation.

Bill Scully (05:56)
We broke up a bit there. I don’t know if that came through. You’re talking about the reciprocal link?

Bill Hunt (05:57)
Right. Let me repeat it, just in case.

If reciprocation is broken, it doesn’t work. For example, say page A (an old U.S. URL) points to page B (the U.K. version). Page A has a canonical to B, but it also 301-redirects to a new page — let’s call it page C (a new U.S. URL).

If page C doesn’t link back to page B, there’s no reciprocation. That breaks the chain.

So in my view — and I even bolded this in my post — that alone is enough to reject the idea that a 301-redirected URL can be used reliably for hreflang.

Bill Scully (06:45)
Right.

Bill Hunt (06:59)
Saying “301s and hreflang are fine” just doesn’t work — because the reciprocation is broken. That’s why I hesitated to respond earlier. I think you were saying that if the UK team had a link back to the correct U.S. page, at least one side of the relationship is intact. But it ends up being a circular reference.

Bill Scully (07:22)
No, no, no — that’s not what I meant.

What I was saying is, if you’ve got a thousand pages and only a hundred of them have redirects, John might be saying that “hreflang is okay” — but those hundred pages won’t work. That was my interpretation.

Bill Hunt (07:40)
Exactly. And I wish he’d just said that. You’re right — if 900 of those pages have a correct hreflang implementation, then those will work. The 100 that don’t? They’ll be broken.

If I had answered that question — and I actually did post a response — I would’ve said: “No, they’re broken. Full stop.”

Then I’d add the clarification you just made: those that are correct will work. Maybe Google can figure some out… but the second point I made in the article is: Google doesn’t always figure it out.

And remember, this was in the context of a migration.

A migration is one of the most fragile transitions you can undertake, because you’re never just changing one thing. There’s this great tweet I always reference in my redirect and migration presentations — it basically says: Every change increases complexity by a factor of ten.

If you change the URL, if you change the content, the template, the layout, remove content, add new content — every one of those variables adds risk. So the last thing we want to do is mess up geo-targeting and hreflang alignment.

That’s why I get so spun up about this.

I had a real case: someone did a migration and assumed Google would “figure it out.” They didn’t update their hreflang tags. Three months later, they came to me and said, “None of our new UK, Ireland, or Australian pages are being indexed — can you help?”

I told them, “Open up Search Console.” We went into the Canonical Duplicate Report for the UK… and nearly 100% of their pages weren’t indexed.

Google had selected the U.S. version of each page as the canonical.

Bill Scully (10:44)
Right — which defeats the whole purpose of hreflang.

Bill Hunt (10:51)
Exactly. There are two big reasons why we strongly advocate for updating hreflang during migrations:

First, it gives each page a purpose. It tells Google explicitly: “This page is for the UK,” “This one is for Ireland,” “This one is for Australia,” etc.

Second, because they’re all interconnected via hreflang, and — Google has said this multiple times — the hreflang system triggers the reciprocation check. It checks whether the UK version links to the U.S. and vice versa, and also checks connections between all other localized versions.

That process causes Google to ingest all of those URLs and crawl them exponentially faster than if it had to discover them on its own.

Bill Scully (11:49)
Yeah, and you really, really shouldn’t be launching and then going back to add hreflang afterward. That’s a killer.

Bill Hunt (11:59)
Exactly — it has to be in place at the moment of launch. If you’re rolling out a new market that’s identical in language, you might have some wiggle room. But if it’s a different language or locale? You’re in trouble.

I guarantee it — I’ve done and fixed hundreds of these. When people skip updating hreflang during a migration, they end up getting penalized for duplication.

In fact, we link to a Google Search Off the Record podcast where they brought on Alan from the Duplicate Content team. He dropped some gold nuggets in that episode. One of the most important was about what he called marauding black holes…

Bill Hunt (12:55)
So, there’s a quote from Alan in that podcast that really stuck with me — and we included it in the article. He said one of the biggest challenges the duplicate content team faces is applying weighted logic when webmasters send conflicting signals.

For example, if your hreflang is incorrect, or maybe you have a canonical pointing from an old page to a new one — and there’s a redirect — maybe Google can piece it together. But Alan dove into this whole concept of “redirect marauding black holes,” especially for e-commerce sites where they use 301s, 302s, and all these workarounds to make pages look temporarily unavailable.

He said all of that creates significant problems for the dupes team.

So that’s really three core reasons why hreflang gets messy — but to bring it back to the main point: I knew it wouldn’t take long for someone to email me and say, “Bill, see? John said it was okay!”

And — sure enough — on Wednesday…

Bill Scully (14:04)
Yeah.

Bill Hunt (14:09)
I got an email from an SEO I’d spoken with just a week earlier. They had added hreflang using Hreflang Builder for their e-commerce site, and they had appended a regional ID to their North American URLs.

Now — just for context — I’m not a developer on Hreflang Builder. I’m just an ambassador and evangelist for the tool. So I sent them over to the support team.

But I explained: the tool can’t interpret that regional ID code. It’s breaking the automated mapping logic that Hreflang Builder uses.

Usually, it maps based on shared SKUs across 67 country sites. But when you append extra parameters — like that regional ID — it disrupts that pattern.

So I told him: “You’ve got two options. You can either add a parameter exclusion to trim it off, or treat it as a variable for mapping. Either way, once that’s in place, the system will remap everything.”

The tool is smart enough to recognize something like NAM-PC — which might just be an internal product code to signify a North American page — and then automatically adjust mappings.

Bill Scully (15:23)
Right.

Bill Hunt (15:37)
So I told him: “Send those regional codes — including the ones you added for APAC — to the team. It’ll take them maybe 15 minutes to rebuild the whole setup.”

But then… I get an email back. He sent a screenshot from Barry’s article, saying: “See? I told you we didn’t need to fix this. Google can understand this.”

Bill Scully (16:07)
Right.

And that — I don’t know the screenshot — but what we were talking about earlier has nothing to do with breaking hreflang. That’s not a redirect issue.

Bill Hunt (16:35)
Exactly. But in this case, it is a redirect. And then he asks if Hreflang Builder can follow this logic — if it can detect redirects and adjust automatically.

The thing is, we’re not crawling those pages. The user’s already paying a fortune for one of the other crawling tools, and we’re importing their data via API. So now he’s trying to push it back on us — or rather, the Hreflang Builder team — because they changed their site and broke things.

At the end of the day, he argued he shouldn’t have to change anything on his website — that Google should just “understand” the old page equals the new one. And that would somehow fix hreflang.

Now, another quick plug for Hreflang Builder: we actually have a migration function. You can take a simple redirect table — old URL to new URL — and upload it.

That gives the system the context it needs: it sees the old URL (which maps to multiple markets) and now adds the new URL to the mapping logic. It’s just like adding another column to the logic table.

So all you need is three columns:

  1. The ID you’re using
  2. The old URL
  3. The new URL

And boom — it remaps it automatically.

Unless you used a wildcard redirect — then you’ll still need to map old to new manually. But otherwise, it works like magic.

So that’s what I told him. The system can fix it. But two days later, here he is — using that article like a blanket excuse.

That’s really the big takeaway: don’t treat a nuanced statement like a universal rule. Just because it might work in one edge case doesn’t mean it applies to every situation — especially not during complex migrations.

Bill Scully (18:36)
Yes.

I want to dig into a few things I’ve heard over the years. You’re like me—we’re always thinking in terms of how a developer would handle something. But there have been some statements that can definitely be misinterpreted. I just want to run through a few of them.

For example, the idea that links aren’t important anymore. What was actually said was:
“Over-focusing on links will often result in you wasting your time doing things that don’t make your website better overall.”

But those are two different things—improving your website overall and obtaining links to help you rank. What people often hear is “backlinks don’t matter for SEO.” What he was really saying is that quality matters more than quantity.

There was also a change in Google’s spam policy documentation around March 20–24. Google uses links as an important factor in determining the relevancy of web pages. So there’s a difference between relevancy and rankings, but we know that links still matter.

Even Gary said at PubCon that links aren’t in the top three ranking factors—maybe they’re the fourth. Also, word count isn’t a ranking factor. People take that to mean that short articles can rank just as well as long ones. But what you really need to do is make sure the content matches the context of the query.

You need to meet searcher intent. You can’t write 50 words that don’t meet the user’s intent and expect it to rank.

Bill Hunt (20:50)
Right. And now you’ve got people talking about AI answer strategies or AI overview strategies—discussing 2,000-word documents that cover every possible nuance or variation of if-then statements that work well for AI agents.

So again, you have two conflicting ideas:

One group says to keep content short and to the point. UX people often recommend short paragraphs and bullet points because nobody reads—people tend to “graze” through content.

But then another group says, “No, you need 2,000 or even 5,000-word documents to really cover the nuances.”

And then there’s the poor person in the middle thinking, “Which is it? What should I do?”

It all circles back to the classic advice: Write for your customer, and everything will be okay.

But here’s where the problem lies. One person says something, and it spreads. I meant to count before this recording, but in our course Understanding and Fixing Hreflang Common Errors, I think I have more than a dozen screenshots where people have made statements like this about hreflang.

For example:
“You don’t have to use a full URL—it can be a relative URL.”

There are a bunch of examples like that. We try to explain why people think this, and we try to debunk it. But at the end of the day, we always return to the actual guidelines.

It comes down to three things:

  1. Why do you need to deviate?
  2. What is your rationale for that deviation or interpretation?
  3. And—this one I might add in a new rant or update an old one—what’s the logic behind your conclusion?

We were just talking about this today. There was a post where John responded to a question someone posted on Bluesky.

Bill Scully (22:50)
Mm-hmm.

Bill Hunt (23:16)
The person was wondering if there’s any SEO benefit to using structured data and schema. He framed it as a question, maybe even a statement.

John responded saying:
“Structured data won’t make your site rank better. It’s used to enable search features listed in the Google documentation. Use it if your page maps to or is appropriate for those features.”

What’s interesting is that three major industry publications picked it up. One person went as far as to say, “John’s a liar.”

Someone else responded, “I use schema, and when we get rich snippets, we get more clicks. And Google’s secret documents say clicks are a ranking factor. Therefore, schema is a ranking factor.”

When I was an undergrad, I took a course on logical fallacies…

Bill Scully (24:10)
Yeah.

Bill Hunt (24:24)
We often fall into traps when interpreting these statements. One of them is called the post hoc trap or the equivocation fallacy, and SEOs are frequently guilty of this. It’s about confusing correlation with causation.

Take schema, for example. Schema might improve how your content appears in search results. It might get your page to show up when answering a question or presenting data properly, which could increase clicks. And those clicks might influence ranking.

But we can’t make the leap and say, “I had a rich snippet, and that rich snippet came from schema, so schema is now a ranking factor.” Schema enables a feature that may lead to an action that may influence rankings.

I think we’ve got a few more examples of these leaps in logic.

Another one—we talked about it back in episode two or three—involved an SEO team from India. Someone there had read a post from a well-known SEO personality who claimed that H1 tags no longer help with SEO. So, they went ahead and removed all the H1 tags from the site.

But H1 tags weren’t just there for SEO. They were part of the design, accessibility, and overall structure. And once they were removed, the site got hammered.

Bill Scully (26:01)
Wow. So you actually had a clean test—just one region on a single domain?

Bill Hunt (26:07)
Exactly. One market.

He only made the change in India. So we analyzed all the pages where traffic had dropped by more than 10%, crawled them, and matched them to their template IDs.

This company was very organized; every page had a template ID. We discovered that all the traffic drops came from just three templates.

When we examined the templates, we saw that the H1 tags were missing. Once we identified who made the change, we asked why. His answer? “Because a celebrity SEO said H1 tags don’t help anymore.”

We asked, “Could they possibly hurt anything?” And he replied, “No, I guess not.”

But yes, they can. For instance, accessibility readers use H1 tags.

Bill Scully (26:57)
Yeah.

Bill Hunt (27:04)
And in this case, accessibility tools flagged those templates because of the missing H1s, which hurt accessibility scoring.

So, we added the tags back in, re-submitted the pages, and almost like magic, they started ranking again.

Was that the only factor? Probably not. But it was enough to reinforce this point: don’t make changes based on a single opinion, especially when that opinion lacks full context.

Bill Scully (27:34)
Right.

Bill Hunt (27:34)
It’s the same kind of thinking that happened when people said, “Google doesn’t use your disallow file.”

I lost count of how many people contacted their agencies saying, “Remove our disallow file!”

If Google doesn’t use it, fine—but does it hurt anything by leaving it? That’s why Google has said not to waste time on disavow files anymore. But again, what’s the logic?

Just like with the H1 situation, if it’s not hurting you, why remove it? That’s how we should approach these things.

Ask:

  • “Is this really what was said?”
  • “Is it universally applicable or an isolated situation?”

Bill Scully (28:17)
Yeah.

Bill Hunt (28:33)
And maybe that SEO wasn’t saying all H1s are bad.

I loved the quote John shared recently—it was an Abraham Lincoln quote:
“If I had six hours to chop down a tree, I’d spend the first four sharpening the axe.”

What he’s saying is: before you make a move, understand the fundamentals. Understand the technical mechanics. A sharp axe is exponentially more effective than just swinging wildly.

And that’s really our message here: Use critical reasoning whenever you read something. Ask yourself:

  • Does this hurt my site?
  • Is this what was actually said?
  • Is this a specific case or a general rule?

It’s extremely rare for Google to make universal statements in a tweet or post without linking to documentation—like something in the Webmaster Guidelines—where they can explain nuances and exceptions.

So again, our main point is: be very cautious when interpreting these sound bites. Always consider the full context.

Bill Scully (29:41)
Yes, absolutely. You have to approach these things like a lawyer. As you break down the comment, ask yourself, “Does this mean that this doesn’t work?” Go through a series of questions, and if something is unclear, then there’s probably a reason for that ambiguity.

Bill Hunt (30:26)
Exactly. You have to go through that decision tree, or a logic tree. Think, “Does this make sense?” And again, like you said, imagine you’re a lawyer or even a 5-year-old—ask the repetitive questions. Spend some time really trying to sort it out. Does this make sense? Is it applicable to me? Is this a universal statement? How could this be wrong? Those critical reasoning steps are key.

Bill Scully (31:03)
Yep. A few more examples I’ve come across: One is the claim that domain authority doesn’t matter. Well, technically, Google doesn’t use domain authority directly as a metric. But what makes up domain authority? It’s a collection of factors Google says are important. It’s about site authority, trustworthiness, and reputation. Domain authority was reverse-engineered to try to approximate how Google’s algorithm works.

I’d definitely prefer a mention or a link from a high domain authority site than one from a low domain authority site. John confirmed that Google has domain-level metrics that align with similar concepts. For example, new content added to an existing domain will inherit certain trust and authority from that domain.

Another one is EEAT. The idea came up, and some people claimed it’s not a ranking signal. True, there’s no single EEAT metric. However, all the components that make up EEAT are used to determine the importance of a page.

Bill Hunt (32:30)
Right, and Google clarified that EEAT isn’t something you can just sprinkle on your site. It ties back to domain reputation—a similar concept. The domain has intrinsic value, relevance, and trust. In our Thinking Like a Programmer and Programmer’s Guide to Technical SEO, we discuss this. Think about crawling: If you had to choose between 50 sites, you’d go for the one that already has a set of data indicating it’s reputable. That’s the whole EEAT concept—signals tell us whether a domain is authoritative and an expert.

Bill Scully (32:37)
Right.

Bill Hunt (32:59)
And this gets to the core issue. A lot of SEOs get into the equivocation fallacy when they try to create these signals artificially. For example, they might put up a knowledge box claiming to be an expert or use schemas without context.

A classic example is when I saw a post in Google Discover yesterday—it was a cooking blog, but the article was about tariff calculations. I thought, why on earth does a chef’s site have anything to do with tariffs? Unless you’re importing goods like Italian truffles, it made no sense. When I clicked on the article, it was clear the author wasn’t a chef—it was someone using a chef’s platform to push a tariff-related article, which had no relevant context.

Bill Scully (34:10)
Yeah.

Bill Hunt (34:26)
It’s fine for a chef to talk about how tariffs impact the ingredients they use, but that’s in context. The problem was that the article had no connection to the chef’s actual area of expertise. SEOs often extrapolate these things, misinterpreting or applying strategies that don’t fit the real intent of content.

It’s the same thing when we hear that domain authority doesn’t matter. Some SEOs use it to sell links, claiming that domain authority scores are a key factor. But the truth is, if your site doesn’t appear to be an authority on a given topic or doesn’t demonstrate consistent expertise in that field, then why would Google want to show it in search results?

I love Danny’s point: If you’re just the 1,157th fried chicken recipe, why should Google include that in the index—let alone show it in the search results?

Bill Scully (34:59)
Right.

Bill Scully (36:37)
Yeah. And thinking like an engineer, how would you rank all of those if everyone updated their title, first sentence, H1, and used alt text? There must be other things they’re using. We know that’s the case.

Bill Hunt (36:58)
Exactly. We need to look at it holistically.

Bill Scully (37:08)
And one other thing: There’s been talk about using AI-generated content. Initially, it was “you can’t,” but now Google says, “you can, but it’s got to be good.” What people hear is “Google approves all AI content,” but what they’re really saying is that AI-generated content can be used as long as it’s quality content. It can’t be spammy or duplicate, and it shouldn’t just be another rehash of existing content.

Content created purely to manipulate rankings, or against Google’s guidelines, is problematic. I’m not sure how you would spot that, but I guess with a churn-and-burn site, it would be pretty obvious. Ultimately, the intent and the outcome matter more than the tool used to create the content.

Bill Hunt (37:56)
Exactly. The question is: why are you doing this? What’s your intent? I worked with a company that built websites for lawyers. They’d sell 30 topical article packages to lawyers who thought that putting out these articles would automatically drive traffic. But it’s like, why would Google consider that relevant if there’s no signal that you’re a trusted authority on the topic? These days, it’s not just about posting content; you need context and credibility.

Bill Scully (38:41)
I know exactly who you’re talking about.

Bill Hunt (38:41)
Right. But nowadays, it’s not just about being careful for them; it’s about being careful with Google. Think about it: today, it’s nearly impossible to have something new gain traction without social media mentions or any form of context. If you launch a product, people are going to talk about it. Some will like it, others won’t. There’ll be news articles about it—people will talk about it, positively or negatively. But the point is, new concepts don’t exist in a vacuum.

If you put out content and there are no signals pointing to it—no social media mentions, no links, and only internal linking—then Google would likely see that as a red flag. It’s almost impossible for content to be relevant or authoritative without external validation.

Bill Scully (39:49)
Right.

Bill Hunt (39:56)
This is especially true for mass-produced content. There’s a difference between writing something and actually having something that’s good and edited before being published. But if you decide to pump out AI-generated content, say 200 sites about the same topic with mixed and matched content to build link networks, Google will see through that. That’s when it doesn’t work.

Bill Scully (40:40)
Yeah, definitely.

Bill Hunt (40:49)
We’ve seen this before, especially with hreflang issues. Companies were trying to push out hundreds of thousands of documents aimed at featured snippets and answer boxes, often with no real value. You can’t just throw out documents on machine learning without any mention of your actual machine learning offering. There’s no context, and Google doesn’t consider that valuable. Simply having a topic isn’t enough anymore.

Bill Scully (41:12)
Exactly.

Bill Hunt (41:18)
You know, in one of these cases, we found that between 65% and 85% of the content was published on 20 or more websites. The company that produced it just extracted it, modified it a bit, and then distributed it. But there wasn’t a single reference to the company itself, except for a link back to their machine learning page or an artificial intelligence page, which in turn linked back to the machine learning page. But no one integrated the company’s actual machine learning or AI offerings.

This is where people get into trouble. They aren’t adding value. There’s no context to their larger business. The content doesn’t align with their offerings. And I think, at the end of the day, it all comes down to how well you write these prompts. You can write prompts that produce amazing content and then have people review it. You can even be your own advisor, create a personal brand around it. But if the content doesn’t serve a real purpose, it won’t be valuable.

Bill Scully (42:40)
Yeah, I get it.

Bill Hunt (42:45)
The point is, people hear “AI content is good,” and think, “Let’s pump it out by the ton and Google will love it.” But that’s not what we’re saying. It’s about creating meaningful and quality content, not just about the tool you use to produce it.

Bill Scully (42:45)
Exactly.

Bill Hunt (43:58)
So, I want to touch on one more point: Google doesn’t use bounce rate for rankings. What people hear is that user behavior doesn’t affect SEO, but what’s really meant is that Google doesn’t use Google Analytics bounce rate as a direct ranking signal. But that doesn’t mean user engagement isn’t important.

Google is always talking about user satisfaction. One thing they can measure, without relying on Google Analytics, is pogo sticking—when someone clicks a result, goes to your site, and immediately hits the back button. We know Google uses terms like long clicks and dwell time in their documentation.

Bill Scully (44:03)
So while bounce rate is a metric in GA, it’s still important to ensure good user engagement on your site.

Bill Hunt (44:10)
Exactly.

Bill Scully (44:12)
So, the takeaway here is to always think critically. Don’t just base decisions on a headline or a social media post. Context is crucial. Think like a lawyer—analyze everything. Google isn’t going to give away its secrets. They need to protect their intellectual property.

Bill Hunt (45:10)
Right, just take the time to understand things, challenge the information, and see if it holds up. Build your strategy based on that understanding. And if something’s not broken, why fix it?

Bill Scully (45:43)
Exactly. Don’t fix what’s not broken.

Bill Hunt (45:54)
Right, if it’s working, don’t change it.

Bill Scully (45:55)
Thanks, Bill. It was great seeing you.

Bill Hunt (45:59)
Good seeing you too. Have a great day!