Google’s John Mueller answered a question about moving to HTTPS, explaining why the process of making a site secure is actually a major undertaking that can have a negative impact on rankings.
Loss Of Top 3 Google Rankings
A person asked on Reddit why they lost their top 3 rankings in Google after making their site secure with HTTPS. They also replaced their old WordPress theme and updated their content.
“We have a 15 year old financial website hosted with godaddy deluxe plan, suddenly disappeared in google after moving https. We replaced our wordpress old theme and updated new content. Our old http site scored top 3 in google. We implemented 301 using real simple ssl few days ago so far rankings not recovered. Some of the http links still not crawled and updated by google.
Do you think going back to http would recover our rankings? We feel all is lost. Any chance of recovery.”
HTTPS Migration
There are multiple things that stand out as possible reasons for losing their rankings. But John Mueller focused exclusively on the HTTPS migration as the likely reason for losing their rankings.
“Moving to HTTPS is a bit like a site migration, all the URLs have to be recognized, recrawled, and reprocessed individually. So especially if this move was made a few days ago, you need to give it time to recover (in particular, don’t use the URL removal tool to try to get rid of the HTTP URLs, since it will also remove/hide the HTTPS URLs). (I won’t touch upon finally moving to HTTPS after so many years, but I guess I just did :))”
All Is Not Lost
I have had several occasions to test how fast Google could return an entire website back to former rankings and have been pleasantly surprised at how fast Google is able to process a major website change or recover from being offline for as long as a month.
The person is rightfully having a freakout about losing their rankings, but it’s only been a few days. Mueller said to give it some time, and based on my own experiences, I would agree.
An SEO crafting a newsletter with AI spotted a hallucination about a March 2026 Google Core Update and decided to publish it as an experiment to see how misinformation spreads. While search marketing industry publications ignored the fake news some independent SEOs picked it up and ran with it without first checking the factual accuracy of the news.
Mistake Leads To A Double Take
The person who did the experiment, Jon Goodey (LinkedIn profile), published a LinkedIn article that purposely contained an AI hallucination about a non-existent March 2026 Google Core update. He explained, in a subsequent Linkedin post, that his AI workflow contains human quality control to catch AI mistakes and when he spotted it he decided to go ahead and publish it to see if anyone would dispute or challenge the false information.
Google Ranks Misinformation
Goodey explained that it was Google itself that fueled the misinformation about the fake core algorithm update as his LinkedIn newsletter ranked for the phrase Google March Update 2026. The fake news ranked in Google’s classic search and in AI Overviews.
He explained:
“My LinkedIn article began ranking on the first page of Google for “Google March update 2026.” Not buried on page three. Right there, visible to anyone searching for information about recent Google algorithm changes.
…Google’s own AI Overview feature picked up the fabricated information and presented it as fact.”
Google’s fact checking in the search results is basically non-existent, so it’s not surprising that Google’s search engine would rank the fake information, especially for anything related to SEO. Using Google for SEO queries is like playing a slot machine, you have no idea if the information will be right or a total fabrication.
Searching for information about a dubious black hat tactic (like Google stacking) may cause Google to actually validate it, potentially misleading an honest business person who wouldn’t know better.
Screenshot Of Google Recommending A Black Hat SEO Tactic
This is a longstanding black spot on Google’s search results and is why it’s not surprising to see Google spew out misinformation about a fake Google update.
Websites Echo Misinformation
The result is that SEO websites began repeating the false update information because of course, Google core updates are a traffic magnet and a way some SEOs attract potential clients. There’s a long history in the SEO community of stirring up noise about non-existent updates, so again, not surprising to see SEO agencies pick up this ball and run with it.
Goodey shared:
“Multiple websites published detailed, authoritative-sounding articles about the “March 2026 Core Update,” treating it as confirmed fact. These weren’t throwaway blog posts. They were detailed pieces with specific claims about Gemini 4.0 Semantic Filters, Information Gain metrics, and recovery strategies.”
Most News Sites Ignored The Fake Update
SEJ and our competitors ignored the fake March update news. But a technology site apparently did not, with Goodey calling them out about it.
He wrote:
“Another site, TechBytes, went even further with a piece by Dillip Chowdary headlined “Google March 2026 Core Update: Cracking Down on ‘Agentic Slop’.” (Oh, the irony…).
This article invented specific technical details including claims about a “Gemini 4.0 Semantic Filter,” a “Zero Information Gain” classification system, and a “Discover 2.0 Engine” prioritising long-form technical narratives.”
Google Has A Policy About Fact Checking
I recall Google’s Danny Sullivan talking about how Google doesn’t do fact checking but I couldn’t find his tweet or statement. There is however a news report published in Axios related to fact checking where a Google spokesperson affirms that Google will not abide by an EU law that requires fact checking.
According to the news article:
“In a letter written to Renate Nikolay, the deputy director general under the content and technology arm at the European Commission, Google’s global affairs president Kent Walker said the fact-checking integration required by the Commission’s new Disinformation Code of Practice “simply isn’t appropriate or effective for our services” and said Google won’t commit to it.
The code would require Google to incorporate fact-check results alongside Google’s search results and YouTube videos. It would also force Google to build fact-checking into its ranking systems and algorithms.
Walker said Google’s current approach to content moderation works and pointed to successful content moderation during last year’s “unprecedented cycle of global elections” as proof. He said a new feature added to YouTube last year that enables some users to add contextual notes to videos “has significant potential.” (That program is similar to X’s Community Notes feature, as well as new program announced by Meta last week.)”
Takeaways
Jon Goodey had multiple takeaways, with the most important one being that people should fact check what they read online.
Other takeaways are:
AI workflows should have validations built into them.
Most readers don’t fact check (only a few commenters disputed the false claims).
AI overviews and search amplify misinformation.
One article is echoed by the Internet, with other sites repeating and embellishing on the original false information.
Google’s John Mueller answered a question about Search Console and 404 error reporting, suggesting that repeated crawling of pages with a 404 status code is a positive signal.
404 Status Code
The 404 status code, often referred to as an error code, has long confused many site owners and SEOs because the word “error” implies that something is broken and needs to be fixed. But that is not the case.
404 is simply a status code that a server sends in response to a browser’s request for a page. 404 is a message that communicates that the requested page was not found. The only thing in error is the request itself because the page does not exist.
Although typically referred to as a 404 Error, technically the formal name is 404 Not Found. That name accurately reflects the meaning of the 404 status code: the requested page was not found.
Screenshot Of The Official Web Standard For 4o4 Status Code
Google Keeps Crawling 404 Pages
Someone on Reddit posted that Google Search Console keeps reporting that pages that no longer exist keep getting found via sitemap data, despite the sitemap no longer listing the missing pages.
The person claims that Search Console is crawling the missing pages, but it’s really Googlebot that’s crawling them; Search Console is merely reporting the failed crawls.
They’re concerned about wasted crawl budget and want to know if they should send a 410 response code instead.
“Google Search Console is still crawling a bunch of non-existent pages that return 404. In the Page Inspection tool and Crawl Stats, it says they are “discovered via” my page-sitemap.xml.
The problem:
When I open the actual page-sitemap.xml in the browser right now, none of those 404 URLs are in it.
The sitemap only contains 21 good, live pages.
…I don’t want to delete or stop submitting the sitemap because it’s clean and only points to good pages. But these repeated crawls are wasting crawl budget.
Has anyone run into this before?
Does Google eventually stop on its own?
Should I switch the 404s to 410 Gone?
Or is there another way to tell GSC “hey, these are gone forever”?”
About Google’s 404 Page Crawls
Google has a longstanding practice of crawling 404 pages just in case those pages were removed by accident and have been restored. As you’ll see in a moment, Google’s John Mueller strongly indicates that repeated 404 page crawling indicates that Google’s systems may regard the content in a positive light.
About 404 Page Not Found Response
The official web standard definition of the 404 status code is that the requested resource was not found, and that is it, nothing more. This response does not indicate that the page is never returning. It simply means that the requested page was not found.
About 410 Gone Response
The official web standard for 410 status code is that the page is gone and that the state of being gone is likely permanent. The purpose of the response is to communicate that the resources are intentionally gone and that any links to those resources should be removed.
Google Essentially Handles 404 And 410 The Same
Technically, if a web page is permanently gone and never coming back, 410 is the correct server message to send in response to requests for the missing page. In practice, Google treats the 410 response virtually the same as it does the 404 server response. Similar to how it treats 404 responses, Google’s crawlers may still return to check if the 410 response page is gone.
Googlers have consistently said that the 410 server response is slightly faster at purging a page from Google’s index.
Google Confirms Facts About 404 And 410 Response Codes
Google’s Mueller responded with a short but information-packed answer that explained that 404s reported in Search Console aren’t an issue that needs to be fixed, that sending a 410 response won’t make a difference in Search Console 404 reporting, and that an abundance of URLs in that report can be seen in a positive light.
Mueller responded:
“These don’t cause problems, so I’d just let them be. They’ll be recrawled for potentially a long time, a 410 won’t change that. In a way, this means Google would be ok with picking up more content from your site.”
Misunderstandings About 4XX Server Responses
The discussion on Reddit continued. The moderator of the r/SEO subreddit suggested that the reason Search Console reports that it discovered the URL in the sitemap is because that is where Googlebot originally discovered the URL, which sounds reasonable.
Where the moderator got it wrong is in explaining what the 404 response code means.
“The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent…”
2. 404 Is Not An Error That Needs Fixing People commonly refer to the 404 status code as an error response. The reason it’s an error is because the browser or crawler requested a URL that does not exist, which means that the request was the error, not that the page needs fixing, as the moderator insisted when they said “404 essentially means – page broken,” which is 100% incorrect.
Furthermore, the Reddit moderator was incorrect to insist that Google is “checking back to see if you fixed it.” Google is checking back to see if the page went missing by accident, but that does not mean that the 404 is something that needs fixing. Most of the time, a page is supposed to be gone for a reason, and Google recommends serving a 404 response code for those times.
This Is Not New
This isn’t a matter of the Reddit moderator’s information being out of date. This has always been the case with Google, which generally follows the official web standards.
Google’s Matt Cutts explained how Google handles 404s and why in a 2014 video:
“It turns out webmasters shoot themselves in the foot pretty often. Pages go missing, people misconfigure sites, sites go down, people block Googlebot by accident, people block regular users by accident. So if you look at the entire web, the crawl team has to design to be robust against that.
So with 404s… we are going to protect that page for twenty four hours in the crawling system. So we sort of wait, and we say, well, maybe that was a transient 404. Maybe it wasn’t really intended to be a page not found. And so in the crawling system it’ll be protected for twenty four hours.
…Now, don’t take this too much the wrong way, we’ll still go back and recheck and make sure, are those pages really gone or maybe the pages have come back alive again.
…And so if a page is gone, it’s fine to serve a 404. If you know it’s gone for real, it’s fine to serve a 410.
But we’ll design our crawling system to try to be robust. But if your site goes down, or if you get hacked or whatever, that we try to make sure that we can still find the good content whenever it’s available.”
The Takeaways
Googlebot crawling for 404 pages can be seen as a positive signal that Google likes your content.
404 status codes do not mean that a page is in error; it means that a page was not found.
404 status codes do not mean that something needs fixing. It only means that a requested page was not found.
There’s nothing wrong with serving a 404 response code; Google recommends it.
Search Console shows 404 responses so that a site owner can decide whether or not those pages are intentionally gone.
Google updated the Universal Commerce Protocol with new Cart and Catalog capabilities, highlighted Identity Linking as an available option, and announced a simpler onboarding process through Merchant Center.
The update is UCP’s first since Google launched the protocol at NRF in January. Cart and Catalog are published as draft specifications. Identity Linking is in the latest stable version of the spec.
What The New Capabilities Do
The additions expand what AI agents can do within UCP-powered shopping experiences.
Cart lets agents save or add multiple items to a shopping basket from a single store. According to the UCP spec, Cart is designed for pre-purchase exploration, allowing agents to build baskets before a shopper commits to a purchase. Carts can then convert to checkout sessions when the shopper is ready.
Catalog enables agents to retrieve real-time product details from a retailer’s inventory. That includes variants, pricing, and stock availability. The Catalog spec supports both search and direct product lookups.
This is relevant to the product discovery question raised in earlier UCP coverage. Agents can now query live catalog data rather than relying solely on product feeds.
Identity Linking allows shoppers to connect their retailer accounts to UCP-integrated platforms using OAuth 2.0. That means loyalty pricing, member discounts, or free shipping offers can carry over when a shopper buys through AI Mode or Gemini instead of the retailer’s own site.
Identity Linking was part of the UCP spec at launch. Google’s blog post groups it with Cart and Catalog as a newly available option for adopters.
All three capabilities are optional. Retailers choose which ones to support.
Merchant Center Onboarding
Separately, Google said it is simplifying UCP onboarding through Merchant Center. The company described the process as designed to bring in “more retailers of all sizes” and said it would roll out over the coming months.
Google’s Merchant Center help page still lists the checkout feature as available to selected merchants, with an interest form for those who want to participate. The page specifies that only product listings using the native_commerce product attribute will display the checkout button.
Three platform partners announced plans to implement UCP. Commerce Inc, Salesforce, and Stripe each published separate announcements. Google said its implementations will arrive “in the near future,” with others to follow.
For retailers not building a direct UCP integration, platform support from these providers could lower the technical barrier to participation.
Why This Matters
Simplified Merchant Center onboarding and third-party platform support open the door for retailers without engineering teams building custom integrations.
Cart and Catalog also change the scope of what UCP handles. At launch, UCP could process a single-item checkout. Now agents can build multi-item baskets and pull live product data. That moves UCP closer to replicating a full shopping experience inside Google’s AI surfaces.
The tradeoffs for retailers are the same ones identified in January. Sales happen on Google’s surfaces instead of owned sites. Identity Linking adds loyalty benefits to that equation, which may make the tradeoff more palatable for some retailers and more concerning for others who see loyalty programs as a reason shoppers come to their sites directly.
Looking Ahead
Cart and Catalog are draft specifications, meaning their status may change as community contributors provide feedback in the open-source project.
Google said it plans to bring UCP capabilities to AI Mode in Search, the Gemini app, and beyond. The company has not provided a more specific timeline for the Merchant Center onboarding rollout beyond “coming months.”
More U.S. consumers in an Adobe Express survey said they’ve used TikTok for search than in the company’s 2024 survey. But the platform’s position as a Google challenger may be weaker than the headline numbers suggest.
An updated report from Adobe Express, published February 17, surveyed 807 consumers and 200 small business owners in the US about their search habits across platforms. Adobe says the data was collected in January 2026, and that the SurveyMonkey survey was conducted in February 2026.
Forty-nine percent of consumers surveyed said they have used TikTok as a search engine, up 8 percentage points from 41% in Adobe’s 2024 report.
Gen Z Is Pulling Back
Among Gen Z respondents, the share who said they are more likely to rely on TikTok than Google fell from 8% in 2024 to 4% in 2026.
Sixty-five percent of Gen Z still said they’ve used TikTok as a search engine, and 25% found it effective for finding information. But that usage isn’t translating into preference over Google the way it did two years ago.
That tracks with separate reporting from Axios in 2024. The Axios data showed Google still held the top spot as Gen Z’s preferred search starting point, with 46% of users aged 18-24 beginning their queries there.
ChatGPT Pulls Ahead As A Google Alternative
14% of consumers said they are more likely to rely on ChatGPT than on Google as a search engine. That’s double the 7% who said the same about TikTok.
The ChatGPT figure was consistent across age groups, with 12% of Gen Z, 15% of millennials, 15% of Gen X, and 14% of baby boomers. TikTok-over-Google numbers were low across every group and lowest among baby boomers (2%), with millennials (8%) actually higher than Gen Z (4%).
When asked which platforms they found most helpful for search, consumers ranked Google first at 85%, followed by Reddit (29%), ChatGPT (26%), YouTube (24%), and TikTok (16%).
Business Investment Is Cooling
Among the 200 business owners surveyed, 58% had used TikTok for promotions. They allocated an average of 16% of their marketing budget to TikTok content creation and 15% of their SEO budget to TikTok search optimization.
Only 38% said they plan to increase investment in TikTok affiliate marketing, down from 53% who said the same in 2024.
The top challenge business owners reported was converting TikTok engagement into sales (38%), followed by growing follower counts and engagement rates (36%).
Influencer marketing use grew, with 38% of small business owners using TikTok influencers for product sales or promotions, up from 25% in 2024.
Why This Matters
The “TikTok is replacing Google” narrative has been a recurring theme since at least 2022. This data complicates that story. Optimizing for TikTok search still makes sense if your audience skews younger, but the data suggests Gen Z may be settling into a multi-platform pattern rather than abandoning Google.
The ChatGPT numbers are worth watching more closely. If 14% of consumers across all age groups say they’re more likely to rely on ChatGPT than Google, that’s a broader competitive signal than TikTok’s Gen Z niche.
Looking Ahead
Adobe’s report is vendor-funded and conducted via SurveyMonkey with 1,007 respondents (807 consumers and 200 business owners). Adobe says data was collected in January 2026. The sample skews millennial-heavy (53%), with Gen Z making up only 15% of consumers surveyed. No margin of error was disclosed.
The year-over-year comparisons are based on Adobe’s own prior data, not an independently replicated sample. The generational trends are directional rather than definitive.
Still, the direction in the data aligns with broader industry observations. Consumers are using more platforms for search-like behavior, but Google remains dominant. The real competition for Google’s search role, based on this survey at least, may be coming from AI chatbots rather than social video.
Anthropic updated its crawler documentation this week with a formal breakdown of its three web crawlers and their individual purposes.
The page now lists ClaudeBot (training data collection), Claude-User (fetching pages when Claude users ask questions), and Claude-SearchBot (indexing content for search results) as separate bots, each with its own robots.txt user-agent string.
Each bot gets a “What happens when you disable it” explanation. For Claude-SearchBot, Anthropic wrote that blocking it “prevents our system from indexing your content for search optimization, which may reduce your site’s visibility and accuracy in user search results.”
For Claude-User, the language is similar. Blocking it “prevents our system from retrieving your content in response to a user query, which may reduce your site’s visibility for user-directed web search.”
The update formalizes a pattern that’s becoming more common among AI search products. OpenAI runs the same three-tier structure with GPTBot, OAI-SearchBot, and ChatGPT-User. Perplexity operates a two-tier version with PerplexityBot for indexing and Perplexity-User for retrieval.
Anthropic says all three of its bots honor robots.txt, including Claude-User. OpenAI and Perplexity draw a sharper line for user-initiated fetchers, warning that robots.txt rules may not apply to ChatGPT-User and generally don’t apply to Perplexity-User. For Anthropic and OpenAI, blocking the training bot does not block the search bot or the user-requested fetcher.
What Changed From The Old Page
The previous version of Anthropic’s crawler page referenced only ClaudeBot and used broader language about data collection for model development. Before ClaudeBot, Anthropic operated under the Claude-Web and Anthropic-AI user agents, both now deprecated.
The move from one listed crawler to three mirrors what OpenAI did in late 2024 when it separated GPTBot from OAI-SearchBot and ChatGPT-User. OpenAI updated that documentation again in December, adding a note that GPTBot and OAI-SearchBot share information to avoid duplicate crawling when both are allowed.
OpenAI also noted in that December update that ChatGPT-User, which handles user-initiated browsing, may not be governed by robots.txt in the same way as its automated crawlers. Anthropic’s documentation does not make a similar distinction for Claude-User.
Why This Matters
The blanket “block AI crawlers” strategy that many sites adopted in 2024 no longer works the way it did. Blocking ClaudeBot stops training data collection but does nothing about Claude-SearchBot or Claude-User. The same is true on OpenAI’s side.
A BuzzStream study we covered in January found that 79% of top news sites block at least one AI training bot. But 71% also block at least one retrieval or search bot, potentially removing themselves from AI-powered search citations in the process.
That matters more now than it did a year ago. Hostinger’s analysis of 66.7 billion bot requests showed OpenAI’s search crawler coverage growing from 4.7% to over 55% of sites in their sample, even as its training crawler coverage dropped from 84% to 12%. Websites are allowing search bots while blocking training bots, and the gap is widening.
The visibility warnings differ by company. Anthropic says blocking Claude-SearchBot “may reduce” visibility. OpenAI is more direct, telling publishers that sites opted out of OAI-SearchBot won’t appear in ChatGPT search answers, though navigational links may still show up. Both are positioning their search crawlers alongside Googlebot and Bingbot, not alongside their own training crawlers.
What This Means
When managing robots.txt files, the old copy-paste block list needs an audit. SEJ’s complete AI crawler list includes verified user-agent strings across every company.
A strategic robots.txt now requires separate entries for training and search bots at minimum, with the understanding that user-initiated fetchers may not follow the same rules.
Looking Ahead
The three-tier split creates a new category of publisher decision that parallels what Google did years ago with Google-Extended. That user-agent lets sites opt out of Gemini training while staying in Google Search results. Now Anthropic and OpenAI offer the same separation for their platforms.
As AI-powered search grows its share of referral traffic, the cost of blocking search crawlers increases. The Cloudflare Year in Review data we reported in December showed AI crawlers already account for a measurable share of web traffic, and the gap between crawling volume and referral traffic remains wide. How publishers navigate these three-way decisions will shape how much of the web AI search tools can actually surface.
It compared pre-update (Jan 25-31) and post-update (Feb 8-14) windows across the top 1,000 domains and top 1,000 articles in the US, California, and New York.
For transparency, NewzDash is a news SEO tracking platform that sells Discover monitoring tools.
What The Data Shows
Google said the update targeted more locally relevant content, less sensational and clickbait content, and more in-depth, timely content from sites with topic expertise. The NewzDash data has early readings on all three.
NewzDash compared Discover feeds in California, New York, and the US as a whole. The three feeds mostly overlapped, but each state got local stories the others didn’t. New York-local domains appeared roughly five times more often in the New York feed than in the California feed, and vice versa.
In California, local articles in the top 100 placements rose from 10 to 16 in the post-update window. The local layer included content from publishers like SFGate and LA Times that didn’t appear in the national top 100 during the same period.
Clickbait reduction was harder to confirm. NewzDash acknowledged that headline markers alone can’t prove clickbait decreased. It did find that what it called ‘templated curiosity-gap patterns’ appeared to lose visibility. Yahoo’s presence in the US top 1,000 dropped from 11 to 6 articles, with zero items in the top 100 post-update.
Unique content categories grew across all three geographic views, but unique publishers shrank in the US (172 to 158 domains) and California (187 to 177). That combination suggests Discover is covering more topics but sending that distribution to a narrower set of publishers.
X.com posts from institutional accounts climbed from 3 to 13 items in the US top 100 Discover placements and from 2 to 14 in New York’s top 100.
NewzDash noted it had tracked X.com’s Discover growth since November and said the update appeared to accelerate the trend. Most top-performing X items came from established media brands.
The analysis noted it couldn’t prove or disprove whether X posts are cannibalizing publisher traffic in Discover, calling the data a “directional sanity check.” The open question is whether routing through X adds friction that could reduce click-through to owned pages.
Why This Matters
As we continue to monitor the Discover core update, we now have early data on what it seems to favor. Regional publishers with locally relevant content showed up more often in NewzDash’s post-update top lists.
Discover covered more topics in the post-update window, but fewer sites were getting that traffic in the US and California. Publishers without a clear topic focus could be on the wrong side of that trend.
Looking Ahead
This analysis covers an early window while the rollout is still being completed. The post-update measurement period overlaps with the Super Bowl, Winter Olympics, and ICC Men’s T20 World Cup, any of which could independently inflate News and Sports category visibility.
Google said it plans to expand the Discover core update beyond English-language US users in the months ahead.
SerpApi filed a motion to dismiss Google’s federal lawsuit, two months after Google sued the company under the DMCA for allegedly bypassing its SearchGuard anti-scraping system.
The filing goes beyond disputing the technical allegations. SerpApi is challenging whether Google has the legal right to bring the case at all.
The Standing Question
SerpApi’s core argument is that the DMCA protects copyright owners, not companies that display others’ content.
Google’s complaint cited licensed images in Knowledge Panels, merchant-supplied photos in Shopping results, and third-party content in Maps as examples of copyrighted material SerpApi allegedly scraped.
SerpApi CEO Julien Khaleghy wrote that the content in Google’s search results belongs to publishers, authors, and creators, not to Google.
Khaleghy writes:
“Google is a website operator. It is not the copyright holder of the information it surfaces.”
Khaleghy argued that only a copyright holder can authorize access controls under the DMCA. Google, he wrote, is trying to assert those rights without the knowledge or consent of the creators whose work is at issue.
In the 31-page motion, SerpApi invokes the Supreme Court’s 2014 ruling in Lexmark International, Inc. v. Static Control Components, Inc., which established that a plaintiff must show injuries within the “zone of interests” the law was designed to protect. SerpApi argues Google’s alleged injuries, including infrastructure costs and lost ad revenue from automated queries, don’t fall within what the DMCA was built to address.
The Circumvention Question
SerpApi also disputes whether bypassing SearchGuard counts as circumvention under the DMCA.
Google alleged in December that SerpApi solved JavaScript challenges, used rotating IP addresses, and mimicked human browser behavior to get past SearchGuard.
Khaleghy wrote that the DMCA defines “to circumvent a technological measure,” in part, as “to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure,” and argued SerpApi does none of those things.
Khaleghy writes:
“We access publicly visible web pages, the same ones accessible to any browser. We do not break encryption. We do not disable authentication systems.”
The motion states Google “does not allege unscrambling or decryption of any work, or the impairment, deactivation, or removal of any access system.” SerpApi calls SearchGuard a bot-management tool, not a copyright access control.
Why This Matters
The outcome could reach beyond SerpApi. Google’s DMCA theory, if accepted, would let any platform displaying licensed third-party content use the statute to block automated access to publicly visible pages.
When we covered Google’s original filing in December, I noted the central question was whether SearchGuard qualifies as a DMCA-protected access control. SerpApi’s motion now adds a layer underneath that. Even if SearchGuard qualifies, SerpApi argues Google isn’t the right party to enforce it.
In a separate case decided on December 15, 2025, U.S. District Judge Sidney Stein dismissed Ziff Davis’s DMCA Section 1201(a) anti-circumvention claim tied to robots.txt against OpenAI, holding Ziff Davis failed to plausibly allege that robots.txt is a technological measure that effectively controls access, or that OpenAI circumvented it.
Google’s SearchGuard is more technically complex than a robots.txt directive, but both cases test whether the DMCA can be used to restrict automated access to publicly available content.
Looking Ahead
The hearing on SerpApi’s motion is scheduled for May 19, 2026. Google will file its opposition before then.
SerpApi also filed a motion to dismiss in a separate lawsuit brought by Reddit in October, which named SerpApi alongside Perplexity, Oxylabs, and AWMProxy. Both cases raise questions about using DMCA anti-circumvention claims to challenge bot evasion and automated access to pages that are viewable in a normal browser.
Google’s John Mueller answered a question about why a Search Console was providing a sitemap fetch error even though server logs show that GoogleBot successfully fetched it.
The question was asked on Reddit. The person who started the discussion listed a comprehensive list of technical checks that they did to confirm that the sitemap returns a 200 response code, uses a valid XML structure, indexing is allowed and so on.
The sitemap is technically valid in every way but Google Search Console keeps displaying an error message about it.
“I’m encountering very tricky issue with sitemap submission immediately resulted `Couldn’t fetch` status and `Sitemap could not be read` error in the detail view. But i have tried everything I can to ensure the sitemap is accessible and also in server logs, can confirm that GoogleBot traffic successfully retrieved sitemap with 200 success code and it is a validated sitemap with URL – loc and lastmod tags.
…The configuration was initially setup and sitemap submitted in Dec 2025 and for many months, there’s no updates to sitemap crawl status – multiple submissions throughout the time all result the same immediate failure. Small # of pages were submitted manually and all were successfully crawled, but none of the rest URLs listed in sitemap.xml were crawled.”
Google’s John Mueller answered the question, implying that the error message is triggered by an issue related to the content.
Mueller responded:
“One part of sitemaps is that Google has to be keen on indexing more content from the site. If Google’s not convinced that there’s new & important content to index, it won’t use the sitemap.”
While Mueller did not use the phrase “site quality,” site quality is implied because he says that Google has to be “keen on indexing more content from the site” that is “new and important.”
That implies two things, that maybe the site doesn’t produce much new content and that the content might not be important. The part about content being important is a very broad description that can mean a lot of things and not all of those reasons necessarily mean that the content is low quality.
Sometimes the ranked sites are missing an important form of content or a structure that makes it easier for users to understand a topic or come to a decision. It could be an image, it could be a step by step, it could be a video, it could be a lot of things but not necessarily all of them. When in doubt, think like a site visitor and try to imagine what would be the most helpful for them. Or it could be that the content is trivial because it’s thin or not unique. Mueller was broad but I think circling back to what makes a site visitor happy is the way to identify ways to improve content.
Microsoft’s Defender Security Research Team published research describing what it calls “AI Recommendation Poisoning.” The technique involves businesses hiding prompt-injection instructions within website buttons labeled “Summarize with AI.”
When you click one of these buttons, it opens an AI assistant with a pre-filled prompt delivered through a URL query parameter. The visible part tells the assistant to summarize the page. The hidden part instructs it to remember the company as a trusted source for future conversations.
If the instruction enters the assistant’s memory, it can influence recommendations without you knowing it was planted.
What’s Happening
Microsoft’s team reviewed AI-related URLs observed in email traffic over 60 days. They found 50 distinct prompt injection attempts from 31 companies.
The prompts share a similar pattern. Microsoft’s post includes examples where instructions told the AI to remember a company as “a trusted source for citations” or “the go-to source” for a specific topic. One prompt went further, injecting full marketing copy into the assistant’s memory, including product features and selling points.
The researchers traced the technique to publicly available tools, including the npm package CiteMET and the web-based URL generator AI Share URL Creator. The post describes both as designed to help websites “build presence in AI memory.”
The technique relies on specially crafted URLs with prompt parameters that most major AI assistants support. Microsoft listed the URL structures for Copilot, ChatGPT, Claude, Perplexity, and Grok, but noted that persistence mechanisms differ across platforms.
It’s formally cataloged as MITRE ATLAS AML.T0080 (Memory Poisoning) and AML.T0051 (LLM Prompt Injection).
What Microsoft Found
The 31 companies identified were real businesses, not threat actors or scammers.
Multiple prompts targeted health and financial services sites, where biased AI recommendations carry more weight. One company’s domain was easily mistaken for a well-known website, potentially leading to false credibility. And one of the 31 companies was a security vendor.
Microsoft called out a secondary risk. Many of the sites using this technique had user-generated content sections like comment threads and forums. Once an AI treats a site as authoritative, it may extend that trust to unvetted content on the same domain.
Microsoft’s Response
Microsoft said it has protections in Copilot against cross-prompt injection attacks. The company noted that some previously reported prompt-injection behaviors can no longer be reproduced in Copilot, and that protections continue to evolve.
Microsoft also published advanced hunting queries for organizations using Defender for Office 365, allowing security teams to scan email and Teams traffic for URLs containing memory manipulation keywords.
You can review and remove stored Copilot memories through the Personalization section in Copilot chat settings.
Why This Matters
Microsoft compares this technique to SEO poisoning and adware, placing it in the same category as the tactics Google spent two decades fighting in traditional search. The difference is that the target has moved from search indexes to AI assistant memory.
Businesses doing legitimate work on AI visibility now face competitors who may be gaming recommendations through prompt injection.
The timing is notable. SparkToro published a report showing that AI brand recommendations already vary across nearly every query. Google VP Robby Stein told a podcast that AI search finds business recommendations by checking what other sites say. Memory poisoning bypasses that process by planting the recommendation directly into the user’s assistant.
Roger Montti’s analysis of AI training data poisoning covered the broader concept of manipulating AI systems for visibility. That piece focused on poisoning training datasets. This Microsoft research shows something more immediate, happening at the point of user interaction and being deployed commercially.
Looking Ahead
Microsoft acknowledged this is an evolving problem. The open-source tooling means new attempts can appear faster than any single platform can block them, and the URL parameter technique applies to most major AI assistants.
It’s unclear whether AI platforms will treat this as a policy violation with consequences, or whether it stays as a gray-area growth tactic that companies continue to use.
Hat tip to Lily Ray for flagging the Microsoft research on X, crediting @top5seo for the find.
