Preserving Search Evidence: A Checklist

How to use this list

This is the technical inventory a preservation letter in a search matter has to cover. Counsel drafts the letter; what follows is the list of systems it has to name, because a hold that says “preserve all documents relating to the website” reaches none of them.

Two facts drive the whole list. First, this data lives in platforms and appliances that no ordinary custodial hold touches: a Google property, an analytics property, a hosting account, a CDN, a content management system, and two or three subscriptions. Second, most of it expires on a schedule, without anyone acting, which means the letter is a clock rather than an instruction.

It runs in both directions. Send it and you have put the other side on notice of which systems they will be asked about. Receive it and you have a list of what your own client is currently losing. In matters I have seen go badly, the loss was symmetric and nobody noticed until the data was needed.

The windows that are documented, and the ones that must be established

Be precise about which retention figures are published and which are not, because an opponent will check.

Google Search Console retains roughly sixteen months of performance data on a rolling basis. The window advances daily and the oldest day drops off. This is the single most time-critical export in most search matters.
Raw server access logs are commonly rotated on thirty to ninety day cycles, depending on the host and configuration. CDN logs are frequently kept for less, and on some plans are not retained at all unless streaming to storage was enabled in advance.
Analytics retention is a configurable setting. What it is set to in a given matter is a question of fact, answered from the property's own configuration and captured as a screenshot of that configuration. Do not assume a default figure; establish it, and export event-level detail immediately either way.
Platform business listings — the local business profile and its history — have no retention period that the platform documents. Treat the retention as unknown, establish it as a question of fact if it can be established at all, and export everything the interface will give you now.

Where a figure is not published, say so in the letter rather than inventing one. A preservation demand built on a retention period the platform never stated is the kind of error that gets quoted back at a hearing.

Search and analytics platforms

Google Search Console

Ask for a list of every verified property first, because sites routinely have several — a domain property and separate URL-prefix properties for http, https, www, and subdomains, each holding different data. Then demand a full performance export for each: queries, pages, countries, devices, and search appearance, broken out by date rather than aggregated, for the maximum available window. Also the page indexing report, the crawl statistics report, any manual action or security notices, the sitemaps list with submission dates, and the removals history. Identify every account with owner or full-user access, including agency accounts.

The analytics property

Demand the property and data-stream identifiers, a screenshot of the current data-retention setting and the date it was last changed, the full user access list, event-level exports for the disputed period, and the definitions of any custom channel groupings, filters, or audience segments in use. Channel definitions are configuration, not fact, and a traffic-by-channel chart is meaningless without them. Where an export warehouse or data pipeline exists, demand the raw tables rather than the interface reports.

Other engines and ad platforms

Bing Webmaster Tools holds query and index data for a different engine and is a partial substitute when Search Console data has rolled off. Ad platform reporting — search terms reports, impression share, auction insights — partially substitutes for lost paid-traffic analytics and is held on the advertiser's account. Both belong in the letter for the same reason: they survive when the primary source does not.

Server, CDN, and hosting records

This is the category with the shortest fuse, and the demand has to go to the person who administers the machine rather than to the client's marketing contact.

Raw access logs for the disputed period, in native format, from every origin server and load balancer. Ask specifically that rotation be suspended, in writing, with the date of the instruction recorded.
CDN logs, including edge request logs and cache status, plus the current retention configuration and whether log streaming to durable storage is enabled.
Error logs and application logs covering the same period, which is where deployment failures and server errors appear before anyone notices them in the interface.
Firewall and bot-management rules and their change history, because a rule blocking a search engine's crawler by user agent or by IP range is a common cause of the thing being litigated.
Hosting control panel access records and DNS zone history, with the dates of nameserver and record changes.

Logs matter more than most attorneys expect, because they are the only source recording what the server actually returned to a search engine's crawler, request by request, rather than what someone believes it returned.

The site itself: preserve a crawl, not screenshots

A redesign, a platform migration, or a routine content cleanup destroys evidence that cannot be re-examined afterward, and it destroys it quietly. This is the single most common irrecoverable loss in this discipline, and screenshots do not prevent it, because a screenshot answers only the questions you thought to ask on the day.

Preserve a full crawl instead — an automated retrieval of every reachable URL on the site, recording for each the status code returned, the response headers, the full redirect chain, the title and meta description, the meta robots directive, the rel="canonical" value (the <link> element telling a search engine which of several similar URLs it should treat as the one to index), the hreflang annotations, the internal links, the structured data, and the rendered page after JavaScript has run. Retain the raw response bodies, not only the summary table, and store the crawl with its date, the user agent, and the tool and version.

Then re-crawl on a schedule for as long as the site is in dispute. A single crawl proves one state. Two crawls with a change between them prove a change, which is usually the fact in issue. Where the disputed pages have already been removed, a crawl of what remains is still worth having, because internal linking, redirect behavior, and status codes tell you what happened to the missing pages.

The change record

Almost every search dispute turns on what changed, when, and in what order relative to some event — a launch, a demand letter, an algorithm update, a termination. That question is answered from the change record, and the change record is usually the part of the letter that gets left out.

Deployment and version control history — commit logs, release notes, and deployment timestamps, with the identity of who deployed each release.
Content management revision history — prior versions of each disputed page with author and timestamp, plus the trash or archive where deleted pages go before they are purged.
robots.txt history — the file at the site root instructing crawlers which paths not to request. Every version, with the date each took effect. A single line in this file can remove a section of a site from a search index.
Redirect configuration history — the redirect map or server configuration, versioned, showing when each 301 or 302 was introduced and what it pointed at.
Disavow file versions. The disavow file is the list a site owner uploads asking Google to ignore specified inbound links. It is a versioned, dated document that replaces the prior version on upload, and it is discoverable. Demand every version with its upload date, and the account it was uploaded from.
Tag manager container versions, plugin and theme change logs, and third-party script changes, each of which can alter what analytics recorded without anyone touching the analytics settings.

Subscriptions that die on lapse

A category with a distinct failure mode: the data is not deleted on a retention schedule, it becomes inaccessible the moment somebody stops paying — which, in an agency dispute, is often the week the relationship ended.

Rank-tracking subscriptions. Export the full history for every tracked keyword, with the tracked location, device, language, and the date each keyword was added or removed. The configuration is as important as the numbers, because it defines what was measured.
Link-monitoring and backlink subscriptions. Export the full link table with first-seen and last-seen dates, anchor text — the visible clickable words of a link, which tell a search engine what the target page is about — and the source URLs, and note that first-seen dates record when the vendor's crawler observed a link, not when it appeared.
Uptime, monitoring, and audit tools, which hold dated evidence of outages, response times, and site errors that no other source retains.
The account itself. Keep it paid through the dispute, or export completely before it lapses. Invoices and billing records also establish the coverage period, which matters when the other side argues a gap in the data is a gap in the facts.

Local listings and third-party profiles

Where the dispute touches local visibility, the business listing is often the disputed artifact itself and it is administered entirely by the platform. There is no documented retention period for its history, so the operating assumption is that whatever the interface shows today may not be there later.

Export now: the profile's current state, the category and attribute selections, hours, service areas, photos with their upload dates, posts, the questions and answers, the review history with dates and reviewer identifiers, and any messages from the platform — verification notices, suspension notices, appeal correspondence, and reinstatement decisions. Record the profile identifier and every account with management access, including agency or third-party managers, and preserve the notification email account those messages arrived in, because that mailbox is frequently the only durable copy.

The same applies to review platforms, industry directories, and any listing service that syndicates business data, where the record of what was published and when is held entirely by the third party and is not versioned for you.

Format, custody, and what the demand should say

How the material arrives determines whether it can be used. A few standing requirements:

Native format. CSV, JSON, or the platform's own export — not PDFs of dashboards and not pasted screenshots. A PDF of a report is a summary of data you have not received.
Parameters recorded with every export. Date range, timezone, filters, segments, sampling, and the account and property the export came from. An export without its parameters cannot be reproduced and will not survive examination.
Hashes at collection. Compute a digest of each file when it is exported and record it in a manifest, so that the copy produced in discovery can be shown to be the copy that was collected.
A custody record. Who exported it, from which account, at what time, in what timezone, and where it has been stored since.
Reciprocity. Ask for the same discipline from the other side, and apply it to your own client's collection, because the same defects are available to both.

Finally, date the letter and keep proof of when it was sent. Under Rule 37(e) the duty to preserve attaches when litigation is reasonably foreseeable, and what changed on a website relative to the date of that letter is frequently the only evidence bearing on intent. The letter is not merely an instruction. It is an exhibit.

Frequently Asked Questions

What should a preservation letter in a search case ask for?

Six categories, named specifically. Search and analytics platform exports, with property identifiers and retention settings. Raw server and CDN logs, with a written instruction to suspend rotation. A full crawl of the site, retained with raw responses. The change record — deployments, content revisions, robots.txt and redirect history, and dated disavow file versions. Third-party subscription histories before the accounts lapse. Local listing and profile data with platform correspondence. A letter that says only "preserve all website documents" reaches none of these, because none of them lives in anyone's mailbox.

How long does Google Search Console keep performance data?

Roughly sixteen months, on a rolling basis. The window advances every day and the oldest day falls off the far end, so the data covering the period before a change is the first to disappear. That makes the export time-critical in nearly every search matter, since a dispute that takes months to reach a complaint spends that whole time watching the baseline period roll off. Export queries, pages, countries, and devices for every verified property, broken out by date rather than aggregated.

How long are server and CDN logs usually kept?

Raw server access logs are commonly rotated on thirty to ninety day cycles, depending on the host and its configuration, and CDN logs are frequently kept for less. On some CDN plans nothing is retained at all unless log streaming to durable storage was enabled beforehand. Because logs are the only record of what the server actually returned to a search engine's crawler, request by request, the instruction to halt rotation should go out first, in writing, to the administrator rather than to the marketing contact.

Is a disavow file discoverable?

It is an ordinary document and there is nothing about it that resists discovery. The disavow file is the list a site owner uploads asking Google to ignore specified inbound links. Each upload replaces the previous version, so it is a versioned, dated record of which links a party asked to have discounted and when. In a link-related dispute that timing can matter a great deal, particularly where the upload followed a demand letter. Ask for every version, its upload date, and the account it came from.

What happens to rank-tracking data when the subscription lapses?

It becomes inaccessible, usually without warning and often at the worst moment, because in agency disputes the subscription is cancelled the week the relationship ends. The history is not deleted on a published schedule; it simply stops being available to anyone who is not paying. Export the full history for every tracked keyword together with the tracking configuration — location, device, language, and the date each keyword was added — or keep the account funded through the dispute. Billing records also establish which periods were covered.

Why preserve a crawl of the site rather than screenshots?

Because a redesign destroys evidence that cannot be re-examined, and a screenshot only answers the questions you already thought to ask. A crawl records every reachable URL with its status code, response headers, redirect chain, canonical tag, meta robots directive, internal links, structured data, and rendered output, and retains the raw responses. When a question arises six months later about a page nobody flagged, a crawl can answer it and a screenshot cannot. Re-crawl on a schedule, because a change between two crawls is usually the fact in issue.

Who holds the data when an agency ran the work?

Frequently the agency, which is a problem when the agency is the opposing party. Search Console properties, analytics properties, ad accounts, tag manager containers, rank-tracking subscriptions, and business profile management access are all commonly created under agency credentials. Identify every account with owner or administrator access as the first step, before any export is attempted, and address access and account ownership in the preservation demand itself. Access removed after a termination looks identical to access that was never granted.

Published 2026-08-11