Sitemap Laravel Package

Technical Evaluation

Architecture fit. thepixeldeveloper/sitemap is a framework-agnostic PHP library that builds sitemap XML through a small object graph (SitemapIndex → UrlSet → Url) and serializes via DOMDocument. It has no knowledge of Laravel routing, Eloquent, queues, caching, or config. That is a reasonable fit for one narrow job — an offline/CLI job that turns a query result into a sitemap file — and a poor fit for anything request-scoped. There is no service provider, facade, or publishable config in the package, so "Laravel integration" is entirely glue code you write and own: an artisan command, a route or a static file, an Eloquent query, and a cache/storage write. The library itself is the smallest part of the effort.

Coupling and substitutability. Coupling is low and the API surface is small, which is the package's main redeeming quality. If it is wrapped behind an internal SitemapBuilder interface from day one, swapping it later is a contained task rather than a refactor. If it is called directly from controllers and commands, the exit cost rises with every call site.

Integration feasibility. Composer install is trivial; Composer resolution is the blocker. The last release was 2020-04-03 and the repository is archived, so the php and dependency constraints reflect the PHP 7.x era. On Laravel 10/11/12 (PHP 8.1+) the install will typically fail on platform requirements rather than on a real code incompatibility — the DOM-based code itself is mostly benign under PHP 8. That distinction matters for the estimate: the fix is usually a private fork with a relaxed composer.json, not a rewrite. But a private fork is still a fork, and it must be registered as a VCS/path repository, versioned, and patched by your team.

Technical risk. Risk is asymmetric and worth stating plainly:

• Low security exposure — no network I/O, no auth, no user-supplied input in the generation path, no database writes. It cannot leak data or corrupt records.
• Low functional churn — the sitemap protocol is stable; sitemap XML from 2020 is still valid in 2026.
• High process risk — archived means no CVE response, no PHP 8.4 readiness, no upstream issue triage, and a dependency that reads as unmaintained to any auditor or new hire.
• Real SEO exposure — sitemaps fail silently. A broken generator produces a 500 or malformed XML that search engines quietly drop, and nothing in the package reports that.

Key questions for the owning team.

1. Is this package already in production, or is this a greenfield evaluation? (Answer changes the recommendation from "don't adopt" to "contain and replace".)
2. What PHP version does the target application run? If 8.1+, has anyone actually attempted composer require and captured the failure?
3. How many URLs, and does the implementation handle the 50,000-URL / 50MB-per-file protocol limits and index splitting?
4. Do we need hreflang alternate links, lastmod accuracy, image/video/news extensions, or gzip? The package's coverage of these is the deciding functional factor.
5. Is the sitemap generated per request, on a schedule, or pre-built at deploy? Per-request DOM generation on a large catalog is a latency and memory incident waiting to happen.
6. Who owns the fork if we take one, and what is the trigger to revisit (next PHP major)?

Bottom line. At 135 stars, archived, and four-plus years past its last release, this is not a package to adopt in 2026 for new work. spatie/laravel-sitemap is the maintained, Laravel-native default and covers the same surface. This package is only defensible as existing technical debt with low blast radius — worth containing and scheduling out, not worth an emergency.

Integration Approach

Stack fit. Best case is a Laravel 8/9 application on PHP 7.4–8.0, where the package installs cleanly and needs only wrapper code. On PHP 8.1+ assume a fork. Either way the integration pattern should be identical: a single artisan command (or queued job) that queries models, maps to Url objects, writes to storage/app/public/sitemap.xml, and a static route or CDN path serving that file. Do not generate on request; the library's DOM approach holds the full document in memory.

Migration path. Three viable options, in order of preference for most teams:

1. Replace with spatie/laravel-sitemap — actively maintained, Laravel-native (routes, Eloquent crawling, tags, caching, robots.txt linkage). Recommended for greenfield and for any team already planning a PHP 8 upgrade.
2. Vendor-fork — if the existing code works and volume is small, fork under a private namespace, relax the platform constraint, and pin it. Cheapest path in engineering hours, highest in ongoing ownership.
3. Hand-roll with XMLWriter — ~100–200 lines, zero dependencies, streaming (constant memory). Genuinely competitive here because the protocol is simple and the package is small; this is often the right answer for a TPM weighing a fork against a 200-line replacement.

Compatibility. The functional risk on PHP 8 is low; the constraint risk is high. Verify: ext-dom and ext-libxml present; no reliance on removed 7.x behaviors; whether the code emits deprecation notices under 8.x that would pollute logs at scale. If the choice is fork-over-replace, budget a compatibility test pass rather than assuming breakage.

Sequencing.

1. Audit — inventory every call site and confirm whether the package is actually in the dependency graph today.
2. Freeze — no new usage; add a lint/CI note or composer.json comment so the next developer doesn't reach for it.
3. Isolate — extract all usage behind one internal interface and one generation entry point. This is the step that buys optionality and should not be skipped even if replacement slips a quarter.
4. Replace — swap the implementation behind the interface; validate output byte-for-byte or via sitemap validator against the old file.
5. Remove — drop the dependency, delete the fork, and note it in the architecture decision record.
6. Verify externally — submit the regenerated sitemap in Search Console and confirm indexation does not regress over the following weeks.

Operational Impact

Maintenance. Upstream maintenance is zero — you are the maintainer. For a fork, budget roughly 1–2 engineer-days per year (dependency bumps, PHP major upgrades, incidental patching) plus the one-time setup. For a replacement, the ongoing cost drops to library upgrades you'd do anyway. The hidden cost of keeping it is organizational: every dependency audit, security review, and new-hire onboarding generates the same "why is this archived package here?" conversation until it's resolved.

Support. No maintainer, no issue triage, no security advisories. Community answers for a 135-star archived package are effectively nonexistent, so internal expertise is the only support channel. The mitigating factor is codebase size — it is small enough that any competent PHP developer can read the whole thing — so this is a knowledge-transfer task, not a specialized-hire task.

Scaling. Two hard ceilings to design around:

• Protocol limits — 50,000 URLs and 50MB uncompressed per file. Beyond that you need a sitemap index with child files. Confirm the implementation splits correctly; if it doesn't, a large catalog produces an invalid sitemap that search engines reject wholesale.
• Memory — DOM construction is O(document) in RAM. A 50,000-URL sitemap is tolerable; a 500,000-URL catalog is not. Mitigate by sharding into multiple child sitemaps, generating on a schedule rather than per request, gzipping, and serving the result as a static asset behind a CDN rather than through PHP-FPM.

Failure modes.

• Composer resolution failure on PHP upgrade — most likely failure, and the one that turns a routine platform upgrade into an unplanned ticket.
• Silent sitemap breakage — a 500, empty file, or malformed XML produces no error in your app and no alert; search engines simply stop ingesting. This is the highest-impact failure and the one the package does nothing to prevent.
• Stale sitemap — scheduled generation fails and nobody notices for weeks; new content goes unindexed.
• Deprecation noise on PHP 8 — log volume and monitoring false positives if error reporting is strict.
• Index/child mismatch — index references child files that failed to write.

Mitigations are cheap and should be treated as part of the integration, not optional: validate generated XML against the sitemap XSD in CI, assert non-zero URL count, alert on scheduled-job failure, and monitor the sitemap endpoint's HTTP status externally.

Ramp-up. Low. The API is learnable in under an hour and the domain — sitemap XML — is well documented publicly. The ramp-up risk is not comprehension but context: the next owner needs the architecture decision record explaining why a fork exists, where it is pinned, and what the exit trigger is (realistically, the next PHP major). Without that note, the package will either be defended reflexively or ripped out carelessly.