Sitemapparser Laravel Package

Product Decisions This Supports

• SEO / site-health roadmap. Powers URL discovery for features like sitemap ingestion, crawl seeding, submitted-vs-discovered coverage, orphan-page detection, stale-content and broken-link audits. It is the input layer for those features, not the feature itself.
• Build vs buy on a commodity component. The decision isn't "is this strategic?" — it's "do we own ~300 lines of XML + gzip + index-recursion handling, or consume a library?" At 78 stars and an archived repo, the honest framing is buy the source, own the code: MIT lets you vendor it and treat it as a starting point.
• Content ingestion. Many partner, marketplace, jobs, real-estate and news feeds expose content only as sitemaps. This unblocks import/inventory pipelines where no API exists.
• Migration and replatform tooling. Produce a pre-migration URL inventory and a redirect map source of truth; verify post-migration coverage by diffing old vs new sitemaps.
• Monitoring and competitive intelligence. Scheduled re-fetch and diff to detect newly published pages, dropped pages, or feed regressions.
• What it does not decide for you: rendering, indexing status, content quality scoring, or Search Console parity. If the ask is "tell us why pages aren't ranking," this package is one small input and the roadmap item is much larger than the parser.

When to Consider This Package

Consider it when:

• You're on PHP/Laravel and need to read sitemaps.org-compliant XML, including sitemap indexes and gzipped sitemaps — the two things people most often underestimate when hand-rolling.
• Volume is modest and bursty: queued jobs, admin-triggered imports, nightly audits. Not sustained high-QPS crawling.
• The team would rather not rediscover XML namespace, encoding, and malformed-feed edge cases in-house.
• You can wrap it: your own HTTP fetch, your own allowlist, the library only for parsing.

Look elsewhere or build in-house when:

• Archived status is disqualifying. No security patches, no ongoing PHP-version guarantees, no new sitemap extensions (image, video, news, xhtml:link/hreflang alternates). For anything customer-facing or long-lived, plan to fork-and-pin, or write the parser.
• You need streaming. Most parsers of this class materialize results in memory; verify against your largest real sitemap before committing. A multi-hundred-MB index will bite you.
• You need the surrounding pipeline. robots.txt Sitemap: discovery, rate limiting, retries, backoff, conditional GET, concurrency — expect to build all of it. (The same author's robotstxtparser covers discovery if you stay in the ecosystem.)
• You have outbound-egress constraints. It brings its own cURL fetching layer. In Laravel you'll want Http:: for timeouts, retries, proxies and logging; be prepared to bypass the built-in fetcher and feed it responses.
• Alternatives worth a look: symfony/dom-crawler plus a thin custom parser; a hosted crawler for one-off audits (cheaper than building); spatie/sitemap if the need is generation rather than parsing — a common mix-up in requirements.

Adoption checklist: fork and pin to a commit, wrap behind an interface (see below), build a fixture suite covering nested indexes, .gz, malformed XML, and empty sitemaps, and add SSRF allowlisting on fetched hosts.

How to Pitch It (Stakeholders)

To executives: "We need to read sitemaps for [SEO audit / partner content import]. A small MIT-licensed library gets us most of the way in days rather than weeks. The caveat: it's no longer maintained, so we'd take a copy into our codebase and own it — roughly 1–2 engineer-days of wrapper and test work. That's the low-risk part. The real cost is the pipeline around it — fetching, scheduling, storage, diffing — which we'd be building regardless of which parser we pick."

To engineering: "Focused single-purpose parser: XML in, URLs out, with sitemap-index recursion and gzip handled. Not Laravel-aware — no service provider, no config, and it ships its own cURL fetch layer. My recommendation: bind it behind a SitemapReader interface, keep all fetching in Laravel's HTTP client so we get timeouts, retries, allowlisting and observability, and use the library strictly for parsing. Because it's archived we fork and pin; the exit path is a small in-house parser if we ever need streaming, sitemap extensions, or a security patch."