Interactive Home Entertainment · Common Crawl
Common Crawl Web Corpus
Datadory delivers Common Crawl web corpus data covering 300 billion-plus crawled pages across 94-plus named releases since 2008 - every record one URL capture with its address, capture timestamp, HTTP status, detected content type, payload digest and archive position, normalized into rows you query instead of archives you parse.
API, files, or your warehouse. Daily, weekly, or hourly.
- Where it covers
- Global crawl across every TLD and region reachable under robots-compliant crawling - no region is sampled out, and opted-out sites are absent by documented design
- How far back
- 94-plus named releases preserved from 2008 through the current month; the newest release in our August 2026 snapshot captured pages during July 2026
- How fine
- One record per fetched URL per release, each stamped with its own capture timestamp, status code and payload digest
What is the Common Crawl Web Corpus?
Common Crawl Web Corpus is the Interactive Home Entertainment catalog's view of the web itself: more than 300 billion crawled pages spanning fifteen-plus years, maintained by the Common Crawl project and carried here as queryable rows. Each crawl release - named CC-MAIN followed by year and week, 94-plus of them since 2008 - captures billions of pages during its window, and every capture becomes a record with its own timestamp, HTTP status, detected content type and payload digest. Cumulative volume sits in the petabytes.
The scale matters less than what it represents: a continuous, machine-readable memory of what the public web looked like, release after release, for nearly two decades. Pages that changed, moved or vanished remain here exactly as captured - which is why teams training language models, auditing a brand's digital footprint or studying how misinformation spreads start from this corpus rather than from the live web.
Get a sample of this dataset - name a domain set, content type or date window, and real rows come back before you commit to a feed.
What does a sample row look like?
Two real index records from the newest release in our August 2026 snapshot, shown exactly as they arrive:
url : urlkey : io,itch)/
captured : 20260719035826 mime : text/html
status : 200 length : 18085
digest : DRQK2TQJ5435MVZR5EGKINOYAGUURLU2
segment : crawl-data/CC-MAIN-2026-30/segments/1783663952046.58/warc/…
url : status : 301
redirect : length : 871
captured : 20260719035826 mime : text/html
digest : LGGT76I5HYSS6HQT36GPANELE4H7FWR7Both were captured within the same second, and together they show why this corpus behaves like a database rather than a pile of HTML. The second row is a redirect: the crawler requested the plain-HTTP form of the same domain, got a 301, and the record preserves both the original address and its destination. Site migrations, domain consolidations and canonicalization choices are therefore reconstructable from rows alone. Note the urlkey column too - io,itch)/ is the SURT-canonicalized form of the address, which is what lets billions of captures sort and join consistently across releases.
What fields does the dataset include?
Twelve verified columns per record, defined below. They fall into three groups. Identity fields (WARC-Target-URI, urlkey, WARC-Record-ID) say what was captured and make rows addressable and joinable. Provenance fields (WARC-Date, timestamp, filename, offset, WARC-Payload-Digest, WARC-IP-Address) say when and where the capture happened, down to the byte position inside the originating archive segment - so a single record is pinpointed even inside petabytes. Classification fields (WARC-Type, mime-detected, status) say what kind of exchange occurred, separating document fetches from redirects, errors and non-HTML payloads.
That last group carries most of the analytical weight. Filtering on status isolates live pages from dead links; filtering on mime-detected separates articles from images, PDFs and scripts; and the two together power churn studies - what share of a domain's 2019 pages still returned 200 in 2026 - without opening a single archive container.
What does coverage look like across geography, time and granularity?
Geography: global by construction. The crawler reaches every TLD and region its robots-compliant policy allows, so coverage reflects the public web rather than a country sample. Sites that opt out through robots directives are absent by design, and that absence pattern is steady enough to model explicitly.
Time: 94-plus named releases reach from 2008 to the present, and the newest in our August 2026 snapshot captured pages during July 2026. Because each release is preserved rather than overwritten, a question like "what did this site's pricing page say in March 2021" has a deterministic answer.
Granularity: one record per fetched URL per release, each carrying its own capture timestamp and payload digest. Cut by domain, content type, status code or time window and the cuts compose - a 2019-through-2026 slice of .de news sites returning 200s needs no custom parsing.
How is the data delivered?
API, files, or your warehouse. Daily, weekly, or hourly. Match the channel to the workload: an API for applications that need pointed lookups on demand, files for bulk analysis runs, or direct delivery into your warehouse for teams joining web captures against their own tables. Cadence follows the question - hourly suits monitoring a fast-moving story, weekly suits footprint audits, and long-horizon model training usually wants a fixed historical cut plus a scheduled top-up.
Start smaller than a feed. Get a sample of this dataset scoped to the domains, content types or years you care about, verify the rows answer the question, then scale the delivery.
Who uses this data, and for what?
Language-model and NLP pipelines. The corpus remains the reference text layer for pre-training and domain-adaptive work precisely because it spans decades of natural web text rather than one platform's output. Payload digests make deduplication tractable at petabyte scale.
Brand and competitive footprint audits. Replaying past releases shows what a competitor's site advertised, priced or claimed in a given quarter - including pages since removed, which is often the interesting part.
Search and SEO research. Status codes, content types and canonicalized URL keys across billions of captures support churn, duplication and indexing-behavior studies at a scale no private crawl matches. Our comparison with Chrome UX Report (CrUX) covers when content-layer evidence beats performance telemetry.
Misinformation and media studies. Deleted pages persist as they were captured, so claims about what was published and when resolve against records instead of recollection - the property academic work cites most.
Due diligence on digital footprints. Acquirers and investors checking a company's historical web presence get timestamped, digest-verified evidence rather than screenshots.
Which personas get the most value?
- Data Scientists & ML Engineers - decades of digest-deduplicatable web text and status-labeled captures for pre-training, classification and churn models.
- Competitive Intelligence & Product Teams - replayed snapshots of competitor sites, including content competitors have since removed.
- Market Researchers & Consultants - category-level web-presence trends across fifteen-plus years of releases.
- Journalists, Academics & Students - citable, timestamped evidence of what was published online and when.
- Developers & Data-Product Builders - stable URL keys and record IDs behind archival, monitoring and citation products.
- Investors & Quants - digest-verified digital-footprint evidence during diligence on target companies.
Field dictionary
Every field below is documented against real records. The full dictionary ships with the sample.
| field | type | definition | example |
|---|---|---|---|
WARC-Target-URI | string | URL of the captured resource, present as a header on every response and request record. | |
WARC-Date | datetime | ISO 8601 capture timestamp of the record, precise to the second. | 2026-07-10T08:36:32Z |
WARC-Type | enum | Record class within the archive: warcinfo, request, response or metadata. | response |
WARC-Record-ID | string | Globally unique URN identifier for the record, stable wherever the record travels. | <urn:uuid:019f4b2b-d751-77a8-8d4a-1563367d16f3> |
WARC-IP-Address | string | IP address the crawler contacted for this target, useful for infrastructure and CDN studies. | 104.233.207.97 |
WARC-Payload-Digest | string | SHA-1 digest of the record payload, carrying integrity verification and deduplication at scale. | sha1:NTFVPKOWHJV4IIENQCUBAI5LR4RC3AYW |
urlkey | string | Canonicalized SURT-form URL key used for sorting and lookups, so billions of captures align consistently across releases. | io,itch)/ |
timestamp | string | Capture timestamp in YYYYMMDDHHMMSS form as surfaced in index rows. | 20260719035826 |
mime-detected | string | Content type detected for the captured payload, separating HTML documents from images, PDFs and scripts. | text/html |
status | integer | HTTP status code recorded at crawl time, distinguishing successful fetches from redirects, errors and dead links. | 200 |
offset | integer | Byte position of the record within its referenced WARC segment, pinpointing one capture without scanning whole files. | 262108455 |
filename | string | Relative path of the WARC segment holding the indexed capture; paired with offset it addresses a single record among billions. | crawl-data/CC-MAIN-2026-30/segments/1783663952046.58/warc/... |
What teams do with it
- LLM and NLP training corpora Decades of natural web text with payload digests for deduplication - the standard substrate for pre-training and domain adaptation.
- Historical website reconstruction Replay past releases to recover pages a company has since changed, moved or removed, pricing and claims included.
- SEO and content-churn research Status codes and MIME types across billions of captures quantify link rot, duplication and format shifts.
- Misinformation and media studies Deleted pages persist as captured, letting publication claims be checked against records rather than memory.
- Digital-footprint due diligence Timestamped, digest-verified history of a target company's public web presence before a deal closes.
Questions buyers ask
How many web pages does the Common Crawl Web Corpus cover?
More than 300 billion cumulative pages across 94-plus named crawl releases since 2008, with billions of fresh captures joining at each release and total volume in the petabytes. Every page appears as one record per release, so the same URL can be tracked forward through time across the whole series.
What formats does the data arrive in?
Raw response archives in WARC form, plain-text extractions in WET derivatives, structured metadata in WAT derivatives, and index layers as CDXJ rows or Parquet tables. Datadory normalizes whichever layer you need into consistent rows, so teams consume tables rather than parsing container formats themselves.
How far back does the crawl history go?
To 2008, in releases preserved rather than replaced - 94-plus of them and counting. Deep history is what turns the corpus from a big snapshot into a longitudinal dataset: pricing pages, manifesto posts and defunct domains all remain queryable as they stood on their capture dates.
Can the corpus be filtered down to specific sites or content types?
Yes. Canonicalized URL keys support domain-scoped cuts, detected MIME types separate HTML from images, PDFs and scripts, and status codes isolate live pages from redirects and failures. Filters compose, so a narrow slice - one domain family, HTML only, successful captures only - comes back as ordinary rows.
Does the corpus respect sites that don't want to be crawled?
Sites publish robots directives and register opt-outs, and the crawler honors them, so opted-out pages are absent by design rather than by accident. Read coverage as the reachable public web - and treat the absence pattern as consistent signal you can model explicitly.
Can I get a scoped sample before committing?
Yes - samples are scoped to the domains, content types or years you name, so you can check row quality against your actual question. Request one through the Get a sample of this dataset button and real captures come back, not documentation.
Notes on this record
- Web-scale, in rows 300 billion-plus captures since 2008 arrive as one consistent record schema - queryable, not a pile of HTML.
- Nothing gets overwritten Each of the 94-plus releases stays intact, so historical questions get deterministic answers instead of reconstructions.
- Every row self-describing Capture timestamp, HTTP status, detected type and SHA-1 payload digest ride on every record, so integrity checks are built in.
- Redirects tell migration stories 301 rows preserve both the requested and destination URLs, making domain moves and consolidation traceable from rows alone.
- Joins hold up SURT-canonicalized URL keys align captures across releases and connect cleanly to GDELT, Google Trends and Reddit sets in the same catalog.
See the rows before you pay anything.
Name this dataset and we send real records from it — scoped to the fields you asked for.