WordPress Post Scraper & Content Change Monitor

Monitor WordPress blogs for new posts and meaningful content edits. Export clean titles, excerpts, body text, publication and modification timestamps, category/tag IDs and source URLs. Use it to keep a research database current, watch competitor publishing or refresh a content pipeline for AI analysis.

The Actor reads the public WordPress REST posts endpoint and compares normalized fields across runs. It distinguishes content changes from a timestamp-only update, avoiding alerts when WordPress marks a post modified but its exported content has not changed.

Who this is for

WordPress publishing research and content refresh. Use the WordPress post scraper to maintain a research feed or refresh a content pipeline when public posts are newly observed or edited. It reads the WordPress REST API and compares exported content; it is not a crawler for arbitrary websites.

Quick start

Extract current public posts:

{
  "siteUrls": ["https://wordpress.org/news"],
  "maxPostsPerSite": 100,
  "includeContent": true,
  "outputMode": "all"
}

Monitor newly observed posts and edits:

{
  "siteUrls": ["https://wordpress.org/news"],
  "maxPostsPerSite": 100,
  "watchId": "wordpress-updates",
  "outputMode": "changes",
  "includeContent": false
}

Use the WordPress installation URL. A subdirectory installation needs its subdirectory: https://example.com/blog reads https://example.com/blog/wp-json/wp/v2/posts. Do not paste a specific article, a query URL or the API endpoint itself. The Actor does not auto-discover nonstandard API roots.

How change tracking works

The first successful changes-mode run establishes a baseline and emits a check summary. Later checks with the same Watch ID emit newly observed post IDs and changes to title, excerpt, plain-text body, URL, category IDs or tag IDs. changedFields tells you what differs. Body hashes are compared even when includeContent=false.

Posts are requested in descending modification order, up to your scan limit. This helps surface updates to older posts instead of looking only at their publication date. An old post entering the window for the first time is new to the watch, not necessarily newly published.

titleKeywords is an optional case-insensitive OR filter. It changes output only; all scanned posts are remembered. Changing keywords does not replay previously observed posts. Use a fresh Watch ID to intentionally establish a different baseline.

Output

recordType=post records include:

Field	Meaning
postId, siteUrl, postUrl	Post identity and public source
title, excerpt, content	Normalized plain text; body omitted when requested
publishedAt, modifiedAt	UTC timestamps from WordPress GMT fields, or null if absent/invalid
categoryIds, tagIds	Public taxonomy IDs, not fetched names
changeType	baseline, new, changed or unchanged
changedFields, previousModifiedAt	Changed normalized fields and previous observed modification time
observedAt	Time this Actor successfully checked the site

A check_summary is always returned per successful site check with counts, pages checked, duplicate IDs skipped and a window-limit indicator. source_error records describe failures. The key-value store's SUMMARY records the overall result and spending-limit status.

Pricing

$0.05 per successful site check, including up to 500 scanned posts and their change records, plus $0.00005 per run start at fixed 512 MB memory. Platform usage is included; no per-post or per-summary charge applies.

A successful empty or unchanged site still counts as a check. Unsupported sites or failed source requests do not trigger the site-check event. If a later pagination request fails, the entire site check fails without replacing history or billing its event. The standard start fee still applies.

Example: ten sites checked once cost $0.50005, or $15.0015 if run daily for 30 days. These are buyer costs, not developer earnings. Maximum cost per run is checked before starting each site.

Scope and limits

• Reads public published posts through the standard WordPress REST API. It does not crawl full HTML pages, comments, private posts, user profiles, media libraries or WooCommerce products.
• Supports up to ten HTTPS sites and 1–500 posts per site, default 100. Pagination respects reported page totals and detects the normal end of an exact-size collection.
• Sites with disabled APIs, nonstandard API roots, protection pages, certificates that fail validation or private network addresses are unsupported. The Actor does not bypass those restrictions.
• Protected post bodies cause a failed check, preserving the previous snapshot rather than treating hidden content as an edit.
• Missing posts are not reported as deleted: this is a rolling window, and content can fall outside the scan range. Pagination is not an atomic snapshot and the source can change while it is being read.
• HTML layout changes that produce identical plain text do not trigger content alerts. This is a content monitor, not a visual page monitor.
• History keeps post IDs and field hashes for 90 days since last observation, with a 20,000-ID cap per site. Full historical bodies are not stored in the watch store. A new Watch ID resets history; use non-overlapping schedules for the same ID.

Source reference: WordPress REST Posts API.

Related tools: Google News Keyword Watch, App Store Review Watch, and ATS Job Watch.

Try one source before scheduling

1. Open the Input tab and use one supported source with outputMode: "all" for an immediate export.
2. Check the returned records and the check summary. Confirm the source, coverage and price suit your workflow.
3. To monitor, set a stable Watch ID and outputMode: "changes". The first successful run establishes a silent baseline.
4. Reuse that Watch ID on later runs. A summary without change records means the check completed without matching changes.
5. Add an Apify schedule after the manual checks work. Avoid overlapping runs with the same Watch ID. Use Maximum cost per run to cap event charges.

Public-data monitors by the same developer: browse the catalog.