Daily News & Article Data Collection from 24 Sites

 

The Client

A US organisation running a media-intelligence function — the kind of operation that needs to know, every morning, what was published overnight across a defined set of sources that matter to its domain. Their source list was specific and mixed: 24 websites spanning mainstream news outlets, trade and industry publications, and community forums. Their need was equally specific: a clean, daily, structured feed of everything newly published, delivered in a consistent shape they could analyse, search, and route — regardless of how differently those 24 sites were built.

The brief was, on its surface, one of the most common data requests in existence: "collect the articles from these sites, every day." Its difficulty — and the reason it's worth documenting — is that "these sites" spanned 24 completely different content architectures, and "clean" turned out to be doing enormous work in that sentence.

The Challenge

News and article extraction is deceptively hard, and the difficulty scales with source diversity:

• Every site is built differently. A major news outlet's article page, a niche trade publication's, and a community forum's thread are three unrelated structures — different markup, different content-vs-chrome ratios, different metadata conventions, and different pagination. A pipeline across 24 such sites is not one extractor; it is a coordinated set of source-aware extractors feeding one clean target.

• "The article" must be separated from everything around it. The valuable payload — headline, author, publish date, body text — sits embedded in navigation, related-article rails, advertisements, cookie notices, comment widgets, and newsletter prompts. Extracting the clean article body while discarding the boilerplate is the core technical work, and it's the difference between a usable dataset and a pile of noise.

• Forums are a different beast from news. A forum thread has an original post plus a branching conversation — multiple authors, timestamps, quote-nesting, and reply structure. Treating a forum thread like a news article (one author, one body) throws away exactly what makes forum data valuable. The pipeline had to handle both content types natively.

• Freshness and completeness both matter. A daily media feed has two failure modes: missing something that was published (a completeness gap that means a blind spot), and re-delivering something already seen (duplication that pollutes analysis). Reliable new-content detection across 24 sites, every day, is the operational core.

• Dates and metadata are inconsistently expressed. Publish dates appear in a dozen formats and timezones; author attribution varies; some sites bury the real publish time in metadata while displaying a relative "3 hours ago." Normalising these into consistent, sortable fields is essential for any downstream time-based analysis.

• And these are changing surfaces. News sites and forums redesign, restructure, and shift their markup regularly — the standing case for self-healing extraction on a feed the client depends on arriving complete every morning.

The Actowiz Solution

1. Source-aware extraction into a unified article schema.

Per-site extractors tuned to each of the 24 sources' structures, all feeding one normalised schema: source, URL, headline, author(s), publish datetime (normalised to a standard timezone), clean body text, content type (article vs forum thread), section/category, and collection timestamp. Twenty-four dialects in, one clean language out.

2. Boilerplate-free body extraction.

Content extraction that isolates the article or post body and strips navigation, ads, related-content rails, cookie banners, and widgets — delivering clean text suitable for reading, search indexing, or NLP, not a soup of page furniture. This is the layer that makes the dataset actually usable downstream.

3. Native forum handling.

For the forum sources, thread-aware extraction: original post plus structured replies, per-author and per-timestamp, with conversation structure preserved — so forum data arrives as the branching discussion it is, not flattened into a fake single article.

4. Reliable new-content detection.

Daily change detection per source identifies genuinely new publications, with URL-and-content deduplication (including cross-source dedup where syndicated content appears on multiple sites) so the client's feed contains each item once, no gaps and no repeats.

5. Metadata normalisation.

Publish dates parsed from every format and timezone into consistent sortable datetimes; author attribution standardised; sections and categories mapped where the client wanted consistent taxonomy across sources.

6. Daily delivery in the client's shape.

The full day's new content delivered on schedule in structured form (the client's preferred JSON/CSV), individually-filed or as a searchable consolidated set per their workflow — with per-record lineage.

7. Compliance and content care.

Public, published content collected responsibly with respectful request pacing per our ethical-load standards; content used for the client's monitoring and analysis with appropriate handling of source attribution; personal data in forum content (usernames, any incidental PII) masked at the edge per our compliance framework; copyright-aware handling (the pipeline collects and structures for the client's internal analysis, with attribution and source links preserved — the responsible posture for media data).

Sample Structure (Illustrative)

Article record (sample):

{

  "record_id": "news-2026-08-11-118204",

  "source": "sample_trade_pub",

  "content_type": "article",

  "url": "https://…",

  "headline": "Sample headline text",

  "authors": ["A. Writer"],

  "published_at": "2026-08-11T04:30:00-04:00",

  "section": "industry",

  "body_text": "[clean article body, boilerplate removed]",

  "word_count": 812,

  "collected_at": "2026-08-11T06:05:00-04:00",

  "lineage_id": "lin-2044-n"

}

Daily run summary (sample):

• Mainstream News

• Sites: 9

• New Items: 214

• Dedup Removed: 18

• Avg Freshness Lag: < 2 hrs

• Trade/Industry

• Sites: 10

• New Items: 96

• Dedup Removed: 4

• Avg Freshness Lag: < 4 hrs

• Forums

• Sites: 5

• New Items: 140 threads

• Dedup Removed: 6

• Avg Freshness Lag: < 3 hrs

Sample data — illustrative of deliverable format. Actual delivery is per-article/per-thread with full clean text and normalised metadata.

Engagement Metrics (Representative)

• Sources: 24 (news, trade, forums)

• Content Types: Articles + forum threads (native handling)

• New Items per Day (Typical): 400–500

• Body-Extraction Cleanliness (Audited): 98%+ boilerplate-free

• Delivery: Daily, scheduled, client schema

• Missed-Publication Rate (Audited): Under 1%

• Site Changes Absorbed, First Quarter: 14 (13 auto-repaired)

• Time to Full 24-Source Pipeline Live: 3 weeks

Representative engagement figures — illustrative of project structure.

The Outcome

The client got the thing a media-intelligence function actually runs on: a complete, clean, consistent daily feed that let their analysts start each morning with the day's relevant content already collected, deduplicated, dated, and structured — rather than 24 browser tabs and a copy-paste routine. The boilerplate-free body text meant the feed plugged directly into their search and analysis tools without a cleaning step; the native forum handling meant community discussion (often the earliest signal in their domain) arrived as usable structured conversation; and the sub-1% missed-publication rate meant they could trust the feed as complete rather than treating it as a starting point to double-check.

The consolidation of 24 disparate sources into one schema was the quiet transformation: cross-source analysis (what's being said across outlets and forums about a topic, today) became a query rather than a manual assembly job. And the self-healing layer meant the morning feed kept arriving complete even as sources redesigned — the reliability that turns a data feed from a tool into infrastructure.

The engagement continues with sources added over time onto the same schema, and an enrichment layer (topic tagging and sentiment) explored as a next phase — the pipeline designed so new sources and new processing slot in without disrupting the daily delivery the client now depends on.

Why This Pattern Repeats

Media monitoring, competitive intelligence, research, and content aggregation all rest on the same need: a defined set of sources, collected completely and cleanly, every day, into one consistent shape. The transferable design: source-aware extractors feeding a unified schema, boilerplate-free body extraction, native handling of different content types (article vs thread), reliable new-content detection with cross-source dedup, metadata normalisation, and self-healing collection so a daily-depended-upon feed never quietly arrives incomplete. The value is in completeness and cleanliness — the two things manual and naive approaches fail at first.

Frequently Asked Questions

Can article text be extracted cleanly, without ads and navigation?

Yes — content extraction isolates the article or post body and strips boilerplate (navigation, ads, related rails, cookie notices, widgets), delivering clean text suitable for search indexing and NLP.

How is forum data handled differently from news articles?

Natively — forum threads are extracted as original-post-plus-structured-replies with per-author, per-timestamp, conversation-structure preserved, rather than flattened into a single article body.

How does the pipeline avoid missing or duplicating content?

Daily new-content detection per source with URL-and-content deduplication (including cross-source dedup for syndicated content) ensures each item appears once, with an audited sub-1% miss rate.

Can more sources be added later?

Yes — new sources slot into the same unified schema without disrupting delivery. Contact Actowiz Solutions to scope a daily media pipeline for your source set.