# Changelog of Sitemap Health Monitor: Broken Links, 404 & Noindex Checker (`pankovs/sitemap-health-monitor`) Actor - **URL**: https://apify.com/pankovs/sitemap-health-monitor/changelog.md - **Full Actor documentation**: https://apify.com/pankovs/sitemap-health-monitor.md ## Changelog All notable changes to Sitemap Health Monitor. Sections: Added, Changed, Fixed. ### 0.1.11 (2026-10-12) #### Added - A sitemap that fails to load (for example HTTP 404 or 500) or contains no URLs is no longer silent. The run shows a new `sitemap-error` notice that names each failing sitemap with its HTTP status or reason, and the run's status message says how many sitemaps failed. - Your webhook now also fires when a sitemap starts failing, not only when new issues appear. A sitemap that stays broken alerts once, not on every run. The summary lists these sitemaps in the new `newSitemapErrors` field. If one of your sitemaps is already failing, you get one alert on the first run after this update. - New `charge-limit` notice when the run's maximum charge is reached, telling you how many URLs were checked out of how many, so you know to raise the limit. - New `discovery-root` notice when your website URL has a path (like `https://example.com/news/`): sitemaps are always found from the site's root `robots.txt`, so the whole site is checked. Use Sitemap URLs to check one section. - New Webhook format option: send a chat message to Slack-compatible webhooks on other hosts (Mattermost, Rocket.Chat, Discord with `/slack` at the end of the URL), or always send the full summary JSON. #### Fixed - Slack alerts now arrive. A Slack incoming webhook (`hooks.slack.com`) gets a readable message with the site, the new, open and fixed counts, up to 10 new issues with their URLs and reasons, and any sitemap that started failing. Before, Slack rejected the raw summary and no message was posted. Zapier, Make and other webhooks still receive the full summary JSON. - Sitemaps that use a namespace prefix (`` with ``) are now read. Before, they were treated as empty and no pages were checked. - Sitemap entries with spaces around a CDATA block, or with extra spaces or attributes in the `` tag, are now read instead of being skipped. - A website URL without `https://` (for example `python.org`) now works. Before, the run failed with "Not a valid URL". ### 0.1.10 (2026-10-12) #### Fixed - Running the actor on the same site with different sitemaps (for example one task for the whole site and one for `news-sitemap.xml` only) no longer mixes their results. Before, the smaller run reported the other run's issues as resolved, and the next full run reported them all as new again, with a fresh "first seen" date and an extra webhook alert. Each sitemap selection now keeps its own history. - Your existing history is kept. Runs that find the sitemap automatically compare with the same baseline as before. A task with its own `sitemapUrls` list starts from your earlier results for the pages in those sitemaps, so known issues stay "persisting" with their original "first seen" date and no extra alert is sent. ### 0.1.9 (2026-10-11) #### Fixed - Security: sitemap, page and redirect addresses that point to private or internal networks are now also refused when written in IPv6 form, for example `http://[::ffff:127.0.0.1]/`. Public sites are checked exactly as before. ### 0.1.8 (2026-10-10) #### Added - New issue type `hreflang-mismatch` for multi-language sites: flags pages whose `hreflang` language versions don't link back, return an error (e.g. 404), redirect, or are missing from your sitemap. The issue names each broken pair, e.g. `en -> de (https://example.com/de/): no return link`. - Like every other issue, hreflang problems are reported as new, still-broken or fixed compared with the previous run, and trigger your webhook alert when new. - No extra cost: language versions fetched to verify a pair are not charged. If a version can't be verified this run (timeout, rate limit, bot protection), the earlier result is kept instead of a false alert. ### 0.1.7 (2026-10-10) #### Changed - No user-facing changes in this version. ### 0.1.6 (2026-10-10) #### Added - New issue type `robots-disallow`: flags sitemap URLs that your robots.txt blocks for search engines (Google rules: longest match wins, `Allow` wins ties, `*` and `$` wildcards). - robots.txt is fetched once per site; if it is temporarily unavailable (5xx, 429, timeout) you get a notice instead of false issues. #### Changed - Clearer name and description in Apify Store: Broken Links, 404 & Noindex Checker. - Store description and README now say plainly what the actor is: a scheduled technical SEO audit and broken link checker, with a new Use cases section and a note on how it differs from a one-off site audit. - Listed under the Automation category too, and 4 ready-to-run example tasks: quick one-off scan, scheduled monitor with Slack/Zapier alert, post-deploy / migration QA, and a gentle multi-client check for small sites. - No extra cost for the robots check: each URL is still charged once. ### 0.1.5 (2026-10-10, public launch) #### Added - Checks every URL in your XML sitemap: broken links (4xx/5xx), redirect chains, noindex, canonical mismatch, timeouts. - Scheduled runs compare with the previous run and report issues as new, persisting or resolved. - Webhook alert when new issues appear. - Output schema for Apify Store; default input runs out of the box. #### Fixed (hardened before launch) - HTTP 429 (rate limiting, e.g. Shopify) is no longer reported as a broken link. The actor respects Retry-After, slows down per host and does not charge for rate-limited URLs. - Sites behind Cloudflare / WAF protection: blocked pages are not reported as broken and not charged; one clear notice with allowlist advice. - Runs with `maxUrls` no longer mark unchecked URLs as "resolved". - Relative `Sitemap:` lines in robots.txt are resolved correctly. - Slow sitemaps: 60 s timeout with one retry; site discovery is capped at 2 minutes (no more 10-minute hangs). - No sitemap given: common locations (`/sitemap.xml`, `/sitemap_index.xml`, `/wp-sitemap.xml`, ...) are probed automatically. - Canonical check ignores tracking parameters (utm\_\*, fbclid, gclid, ...).