Every web crawl now contains machine-generated text: product pages written by a model, content-farm articles produced by the thousand, reviews and forum posts that no person wrote. For many uses that is harmless. For training data, evaluation sets and retrieval corpora it is not, and the share keeps growing.
The uncomfortable fact is that no detector reliably identifies generated text document by document. What works is a layered approach: several weak signals combined, calibrated against your own data, and applied with a policy that matches what the dataset is for. This guide covers the signals, how to combine them, and how to collect data so that filtering is possible at all.
The general pipeline for building a scraped dataset, including deduplication and provenance, is in how to build a dataset with web scraping. This guide focuses on the generated-content problem specifically.
Why it matters, by use case
| Dataset use | Risk from generated content | Typical tolerance |
|---|---|---|
| Model pretraining | Homogenised style, amplified errors, loss of rare knowledge | Moderate, with down-weighting |
| Evaluation and benchmarks | Test items that echo model outputs inflate scores | Very low |
| Retrieval corpora for RAG | Confident but wrong passages get retrieved as facts | Low for high-stakes answers |
| Market and social analytics | Fake reviews and posts distort counts and sentiment | Low |
For training, the concern is well documented. Published research has shown that models trained repeatedly on the output of earlier models lose the rarer parts of the original data distribution, a failure described as model collapse. For analytics the concern is simpler: a sentiment trend built on generated reviews measures a marketing campaign, not customers. That problem is covered from the collection side in scraping social platforms for sentiment analysis.
Why a single detector is not enough
AI-text classifiers are tempting because they return a score per document. In practice they are unreliable in exactly the conditions that matter for web data.
- Short texts give them too little to work with.
- Paraphrased or lightly edited text often passes as human.
- Non-English languages are usually less well covered.
- Some human writing is flagged far too often. Studies have found that detectors misclassify writing by non-native English speakers as machine-generated at much higher rates.
One major AI lab withdrew its own public text classifier in 2023, citing low accuracy. Treat a classifier score as one weak feature among several, never as a verdict.
Signals that work better together
Provenance and time
The strongest single signal is not in the text at all. It is when the content was first observed.
Generative text models became widely available to the public in late 2022. Content that was first observed before then is far less likely to be machine-generated, whatever a classifier says about it. Content first seen afterwards is not automatically suspect, but the prior changes.
That only works if you record observation times. Store a first-seen timestamp for every document at collection, keep it through every copy and transformation, and recrawl periodically so you can detect pages that were quietly rewritten later. The case for treating when and where an observation was made as part of the data is set out in the vantage-point standard.
Source-level signals
Generated content is usually produced at scale by a small number of operators, which makes sources easier to judge than individual documents. Score domains and sections, not just pages.
- Publishing velocity. A domain that went from a few pages a month to thousands a week.
- Template uniformity. Many pages sharing one structure and heading pattern, differing only in the topic slotted in.
- Topic sprawl. A single site covering unrelated subjects with uniform depth.
- Missing accountability. No authorship, no about page, no contact details, or invented bylines.
- Monetisation density. Pages that exist mainly to carry affiliate links or ads.
Near-duplicates and templates
Content farms tend to produce many paraphrases of the same outline. Near-duplicate detection, typically MinHash with locality-sensitive hashing over shingled text, clusters those variations together. A large cluster of near-identical pages across many domains is a strong signal of mass production, and inspecting the cluster by hand is far faster than inspecting pages one at a time.
Keep raw HTML for sources you expect to analyse this way, since the template itself is often a clearer signature than the text.
Document statistics
Statistical properties of the text can help, as long as they are treated as weak evidence. Very low perplexity under a reference language model, low variation in sentence length and structure, and heavy use of generic filler phrasing are all associated with generated text.
Each is also common in some human writing: simple documentation, formulaic news briefs and text by non-native writers. Use them only in combination, and calibrate them per language.
Watermarks, where they exist
Some model providers embed statistical watermarks in generated text, and some have released detection tooling. Where a watermark is present and detectable, it is strong evidence. It only covers text from participating models, it can only be checked with the provider’s detector, and paraphrasing or translation weakens it. Treat a positive result as meaningful and a negative one as uninformative.
| Signal | Strength | Main weakness |
|---|---|---|
| First-seen date | Strong for older content | Needs timestamps recorded at collection |
| Source-level patterns | Strong at domain level | Misses one-off generated pages on good sites |
| Near-duplicate clusters | Strong for content farms | Misses original, one-off generation |
| Document statistics | Weak alone | Penalises plain and non-native writing |
| Classifier score | Weak alone | Unreliable on short, edited or non-English text |
| Watermark | Strong when positive | Absent from most text |
From signals to a filtering policy
Combine the signals into a single score per document, with source-level scores feeding into document scores. Then decide what to do with each score band, and let the decision depend on the dataset’s purpose.
- Keep documents that score clearly human or were first seen before your cutoff.
- Down-weight borderline documents in pretraining mixtures rather than removing them.
- Quarantine likely-generated documents in a separate store, so the decision can be revisited when the filter improves.
- Drop only where the use case demands it, such as evaluation sets, where contamination does the most damage.
Version the filter, and record in the dataset’s documentation which version produced which subset. A filter is a set of decisions about the data, and anyone using the dataset later needs to know what those decisions were.
Not all synthetic data is unwanted. Deliberately generated training data has legitimate uses. The problem is generated content that arrives unlabelled and is mistaken for human writing, so where you produce synthetic data yourself, label it at the source.
Measure the filter, including who it wrongly excludes
A filter that nobody has measured is a guess.
Build a labelled validation set from your own crawl: documents from sources you know are human-written, a sample you generate yourself with current models across your target languages, and a random slice of borderline cases reviewed by hand. Measure precision and recall per language and per domain.
Then audit the false positives specifically. If the filter disproportionately removes writing by non-native speakers, plain technical documentation or particular regions, it is quietly narrowing the dataset in a way that will show up later as a model that serves those users worse. The broader risk of an unbalanced dataset is covered in your residential proxy pool is a sample, not the internet.
Rerun the evaluation regularly. Generators improve, and a filter that worked last quarter can degrade without anyone noticing.
Collect so that filtering is possible
Most of the useful signals depend on decisions made at collection time.
- Record first-seen timestamps for every document, and preserve them through every transformation.
- Store source metadata: domain, section, publication date where stated, and the vantage point the page was observed from.
- Keep raw responses for sources you may need to analyse for templates, and land them before parsing so a better filter can be replayed without recollecting. The pattern is in moving web scraping API data into SQL.
- Recrawl on a schedule to detect pages rewritten after first collection.
- Prefer primary human sources: forums, regional sites, documentation and specialist publications, rather than aggregators that recycle them.
Many of the best human-written sources are regional and heavily defended. Reaching them from the right country, consistently enough to recrawl, is where collection infrastructure matters. With the Shifter gateway, the market is set in the credentials against p.shifter.io:443, and omitting a session identifier rotates the exit per request, which suits independent page fetches:
customer-USERNAME-country-br:PASSWORDCollect responsibly: respect each site’s terms, keep request rates proportionate, and avoid collecting personal data you do not need. The wider framing is in ethical residential proxies for AI data collection.
FAQ
Can AI-generated text be reliably detected?
Not reliably for individual documents. Combined signals across sources, clusters and timestamps work far better at dataset scale than any per-document classifier.
Should all generated content be removed from a training set?
Not necessarily. Down-weighting borderline content and labelling intentional synthetic data is usually better than aggressive removal, which also removes a lot of human writing.
Does filtering reduce dataset diversity?
It can, if the filter penalises plain or non-native writing. Audit false positives by language and region before applying a filter at scale.
Is content from before late 2022 safe to treat as human-written?
It is a strong prior, not a guarantee. Earlier automated content existed too. Combine the date with the other signals.
The bottom line
There is no switch that removes AI-generated content from a web dataset. There is a set of signals that each carry some evidence: when content was first seen, how its source behaves, whether it belongs to a cluster of near-duplicates, how its statistics look, and occasionally a watermark. Combined, calibrated on your own data and applied with a policy that fits the dataset’s purpose, they work.
Most of that depends on collecting with timestamps, source metadata and raw responses from the start. The product view is on the AI and machine learning data collection page, and the collection side is covered in collecting web data for AI training.