Statamic Anchor Navigation Laravel Package

Product Decisions This Supports

• Table-of-contents / in-page navigation for long-form content: the addon turns heading structures in Statamic content into anchor navigation (TOC + deep links). This directly supports roadmap items around documentation hubs, knowledge bases, editorial long-reads, and policy/resource pages where scanability and jump-links are the difference between a page being usable and being abandoned.
• SEO and content architecture bets: anchor links and stable heading IDs enable jump-link SERP features, shareable section URLs, and cleaner internal linking. Relevant when deciding whether to invest in "content depth" (long pages) versus "content breadth" (many short pages) — anchor navigation lowers the cost of the depth strategy.
• Accessibility and compliance work: structured in-page navigation supports WCAG-oriented improvements (bypass/skip navigation, keyboard-navigable TOC). Useful leverage when accessibility is a compliance requirement rather than a nice-to-have.
• Build vs. buy for a small, well-bounded capability: this is a narrow addon, not a platform. The honest comparison is "install and configure" versus "write an Antlers partial plus scroll-spy JavaScript plus heading-ID slug logic and maintain it forever." For a capability this small, buy/adopt is almost always the right call unless you have unusual heading or routing requirements.
• Stack upgrade planning: v1.1.0 adds Statamic 6 support and drops Statamic 4. That makes this release a concrete input to your CMS upgrade sequencing — it tells you the addon ecosystem is keeping pace with Statamic 6, and it flags which sites must be pinned if they're still on Statamic 4.
• Vendor/ecosystem risk tracking: the release adds a test suite and a new contributor. Both are positive maintenance signals for a small agency-maintained package, and worth recording when scoring dependency risk in an architecture review.

When to Consider This Package

Adopt when:

• You're on Statamic 5 or 6 and have (or plan) content types with meaningful heading hierarchies — docs, guides, FAQs, long marketing pages.
• You want anchor navigation as a configuration concern rather than bespoke front-end code, and your templates are Antlers-based.
• You're standardizing a docs/knowledge-base pattern across multiple sites and want one consistent implementation.
• You value the newly added test coverage as a signal that the addon will survive Statamic major-version bumps.

Look elsewhere or reconsider when:

• You're on Statamic 4. v1.1.0 drops v4 support — pin to v1.0.0 and treat this as a forcing function to plan the Statamic upgrade, not as a reason to fork.
• You're not on Statamic. This is a Statamic addon; on plain Laravel you'd be evaluating a generic TOC/anchor library or building it in your front-end layer.
• Your navigation needs are structural, not in-page. If what you actually need is a nested sidebar nav, breadcrumbs, or multi-page docs routing, this is the wrong tool — that's a docs-generator or nav-builder decision, not an anchor addon.
• You need guaranteed SLAs or a large maintainer base. This is a small package from an agency; if the feature is on a revenue-critical path and you can't tolerate a lull in maintenance, budget for the option to reimplement (it's a contained surface area, so the exit cost is low).
• Your headings are generated dynamically by rich-text or third-party embeds — validate that anchor generation covers those cases before committing.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost addon that makes long-form content actually usable — readers get a jump-to-section menu and shareable links to specific sections, which improves engagement on docs and resource pages and helps with search visibility and accessibility compliance. The new release keeps us current with Statamic 6 and, notably, adds an automated test suite — meaning the maintainers are investing in durability, not just features. Risk is low and reversibility is high: it's a contained capability we could rebuild in-house in days if we ever needed to.

For engineering: v1.1.0 adds Statamic 6 support and introduces test coverage — treat it as the version to standardize on for Statamic 5/6 projects. It also drops Statamic 4 support, so any site still on Statamic 4 must stay pinned to v1.0.0; that's a breaking change in a minor version bump, so lock versions in composer and audit which properties are affected before the next dependency update. No migration work is required on Statamic 5/6. Action: adopt on new Statamic 5/6 builds, pin v1.0.0 on Statamic 4, and add the Statamic 4 sites to the upgrade backlog.