serp.fast

Google's DMCA claims against SerpApi were dismissed. What that changes in your SERP API contract

On 20 July 2026 a California court dismissed Google's core DMCA claims against SerpApi. What it settles, what it doesn't, and what to put in your SERP contract.

Nathan Kessler

Written by Nathan Kessler

Last updated: 8 min read

Google's DMCA claims against SerpApi were dismissed. What that changes in your SERP API contract

On 20 July 2026, Judge Yvonne Gonzalez Rogers dismissed the central piece of Google's DMCA anti-circumvention case against SerpApi. Search Engine Land reported the ruling the same day, and the litigation tracker ChatGPT Is Eating the World posted the order with the same reading. Both describe the same split: claims premised on search results that contain no copyrighted content were dismissed with prejudice, and claims touching results that do contain copyrighted material were dismissed with leave to amend.

If you buy SERP data, the useful question is not who won. It is what the ruling does to the risk you already carry by routing production traffic through a single vendor with an open federal docket. The answer is less than the headlines implied, and it points at your contract rather than at your vendor choice.

What the court actually held

Per both reports, the reasoning on the dismissed-with-prejudice half is narrow and structural. Section 1201 protects a technological measure that controls access to a copyrighted work. Where the results behind SearchGuard are plain and aggregated output, URLs, snippets and factual index data, there is no protected work for the measure to protect, so the claim fails as a matter of law rather than as a matter of pleading. That is why Google cannot replead it.

The half that survived is the half that involves results carrying copyrightable components. There the defect was factual: Search Engine Land reported that Google had not alleged that SearchGuard was implemented and functions to control access to those components with the authority of the copyright owners, and that the court noted such information should already be in Google's possession. Search Engine Land also reported a 21-day window to replead.

Two other findings matter and got almost no coverage. The court did not accept SerpApi's standing argument, per Search Engine Land's account. And it found Google had alleged enough facts to support an inference that SerpApi circumvented SearchGuard. So the mechanism question, did a technological measure get bypassed, was not resolved in the defendant's favor. Only the object of that measure was.

Why the durable half is the interesting half

Strip the procedure away and one holding is likely to outlive this case: plain search results are not, on their own, copyrighted works, so a technological measure sitting in front of them is not a Section 1201 measure.

That is a real narrowing of the copyright-shaped theory against SERP resale, and it is the part worth planning around, because it does not depend on what Google pleads next. It says something about the category of data rather than about this defendant's conduct. A list of ten blue links, a snippet, a ranking position, an "also asked" block: these are facts about an index, and the ruling treats them as such.

It says nothing about the other theories that plaintiffs bring in the same breath. Terms of service and breach of contract, unjust enrichment, and CFAA claims all sit on different footing, and this ruling does not touch them. Our earlier post on the legal status of web scraping was written before 20 July and maps those theories; the DMCA branch of that map now has a documented limit at the plain-results end, and nothing else moved.

Read narrowly, the win is: the copyright hook does not attach to the factual output of a search index. Read as a general permission, "scraping Google is legal now," it is wrong on the face of the same order, which kept a live circumvention inference and gave the plaintiff three weeks to try again.

The second front is in a different court

A California ruling does not clear New York risk, and the same vendor has a New York problem.

Reddit sued in the Southern District of New York on 22 October 2025 (No. 1:25-cv-08736, before Judge Paul A. Engelmayer), naming SerpApi, Oxylabs, AWMProxy and Perplexity AI. A first amended complaint was filed on 6 February 2026. Reddit's theory there is also DMCA anti-circumvention, but aimed at indirect acquisition: the allegation is that Reddit content was taken at scale out of Google Search results rather than from Reddit directly. As of late July 2026 no ruling on a motion to dismiss in that case has been reported.

That is a different plaintiff, a different court and a different factual posture. Reddit's content is user-generated text, not a snippet of index metadata, so the "no copyrighted work behind the measure" reasoning that ended Google's first theory is a much harder fit. A vendor can be right about one and exposed on the other. Any vendor-risk assessment that stops at the California docket is looking at half the picture.

Litigation rarely kills a vendor. It reprices one

The failure mode people plan for is the wrong one. Vendors in this category do not usually vanish mid-contract. What changes under sustained litigation is coverage, pricing and appetite.

Coverage first. The cheapest way to reduce legal exposure is to stop serving the engine or the result type that generated the claim. A vendor under pressure can quietly drop a locale, an engine, a rich-result block, or the very field your pipeline parses. That arrives as a schema change or a silent null, not as a legal notice.

Pricing second. Defense costs and any settlement land somewhere, and in a business with thin per-thousand-query margins they land on the price list or on the rate limits.

Appetite third. Roadmap commitments slow down when counsel is reviewing them. If you were told a new engine or a new structured field was coming this quarter, litigation is a reason to stop treating that as a date.

None of this is specific to SerpApi, which has been in the market since 2017 and is the most established name in the SERP data API category. It applies to any vendor whose product is other people's search results, and the sector-wide answer is contractual and architectural rather than a matter of picking the vendor with the quietest docket.

Contract language to ask for

Five clauses do the work when a vendor's legal position changes. If you are renewing or negotiating a SERP data contract in the next two quarters, read these line by line.

IP indemnification, and specifically its scope. Most SERP API terms include an indemnity for third-party IP claims against you. What matters is whether it survives a claim arising from the data itself rather than from the software, whether it covers your downstream use of returned results, and what the cap is. An indemnity capped at fees paid in the trailing twelve months is not meaningful coverage for a product built on that feed.

Notice on filing. Ask for written notice within a fixed number of days if a claim is filed against the vendor that relates to the service you buy. Absent this, you learn from a news post, which is how most buyers learned about 20 July.

Service continuity and change control. A commitment that engines, locales and result fields will not be removed without a defined notice period, ideally 60 or 90 days. This is the clause that protects you from the coverage-shrink failure mode, and it is more often absent than refused.

Data portability and cache rights on termination. Two separate questions. Can you export what you have pulled, and in what format? And what happens to results you have already cached or stored if the contract ends or the vendor is enjoined? Many terms grant a license to use results that terminates with the agreement, which would make your existing store non-compliant on the day you leave. If your RAG index or price-history table is built on cached SERP data, get that right in writing.

Sub-processor and sourcing disclosure. Ask how results are obtained and whether third parties are involved. Reddit's complaint names an API vendor and proxy providers together, which is a useful reminder that your vendor's sourcing chain is part of your risk surface.

Dual-sourcing is cheap in this category

SERP APIs are one of the few web data categories where a second source costs almost nothing to keep warm. The interfaces converge: query in, ranked results out, largely overlapping JSON shapes. Most teams can put a thin normalization layer in front and swap the backend with a config change.

Eight vendors in the serp-data-apis category are close enough substitutes to serve as a second source, and they differ mostly on price shape and engine coverage:

VendorWhere it fits as a second source
SerpAPIWidest engine coverage, 80+ engines, the usual primary
Serper.devGoogle-only, published list price around $1 per thousand queries
DataForSEOSERP plus 50+ adjacent SEO data APIs on one contract
SearchAPI.ioMulti-engine with native LangChain and Haystack integrations
ValueSERPBatch jobs up to 15,000 requests, useful for backfill
ScrapingDogVolume-tiered pricing published down toward $0.29 per thousand
ZenserpGoogle SERP with image and reverse image search
HasDataZapier and Make.com connectors for no-code pipelines

The practical setup is not a live failover. It is a second account with a small monthly spend, a normalization layer already written, and a scheduled job that runs the same 200 queries through both and diffs the output so you know your fallback still works. Our comparison of SerpAPI and Serper.dev covers the interface differences in the most common pairing, and the cheapest SERP API breakdown covers what the second account will cost you.

What to watch, and when

Two dates. The 21-day repleading window Search Engine Land reported puts Google's amended complaint, if it files one, in the second week of August 2026. Whether it repleads at all is a signal: declining to amend would suggest the remaining copyrighted-components theory is not worth the discovery it would open.

The other is the still-pending motion to dismiss in Reddit's SDNY case. That court is being asked whether taking user-generated content indirectly, out of a third party's search results, is circumvention. A ruling either way will matter more to the market than the California order did, because it addresses the content type most AI training and grounding pipelines actually want.

What this means if you build on web data

Treat the ruling as a narrowing, not a green light. The durable holding is that plain search results are not protected works. The circumvention inference stood, the standing argument failed, and the case continues.

Your exposure is vendor continuity, not your own liability. A ruling against a vendor is unlikely to reach you directly. A vendor that drops an engine, reprices, or freezes its roadmap reaches you immediately.

Get notice, continuity and cache rights in writing before you need them. Notice on filing, a 60 to 90 day change window on coverage, and explicit rights to data you have already stored are the three clauses that convert a legal surprise into a scheduled migration.

Keep a warm second SERP source and prove it works monthly. In this category the interfaces are close enough that dual-sourcing is a config change, and an untested fallback is not a fallback.

Share:

Tags:

  • #legal
  • #serp-data-apis
  • #market-analysis
  • #api-selection