Yes. Both json_url and json_file are supported. CI can write a releases.json that SleekRank consumes on each cache refresh. Many teams check the file into a public repo, push it to S3, or expose it via a /releases.json endpoint on their docs site. The page-group config points at that URL or path, and a cache flush at the end of the release job propagates the new version to the public site.

Each is an array column. The list mapping repeats a row template inside the base page for every entry in the array. So a release with eight changes and three fixes renders eight bullet rows in the changes section and three in the fixes section. The same pattern works for breaking changes, deprecations, security advisories, or any other categorized notes — just add another array column and another list mapping.

Render Markdown to HTML in your build step and store the rendered HTML in a column. SleekRank inserts it via a selector mapping, which preserves the formatting cleanly inside the base page layout. This pattern works well when release notes are written in Markdown by engineers and need to surface as styled HTML on the marketing site without a separate copy-paste workflow.

No. The release feed comes from your release process — CI, GitHub Releases, semantic-release, or manual entry by the release manager. SleekRank only renders pages from data you provide. This separation lets engineering own the source of truth in their existing tooling while marketing controls the presentation through the base page template, with no shared write access between the two.

Add a status column — stable, beta, alpha, RC — and gate it in the template, or filter pre-releases out of the feed entirely so only stable versions get pages. Some teams maintain two page groups: /release/{slug}/ for stable and /preview/{slug}/ for beta, each with its own JSON file. This keeps SEO equity flowing to stable URLs while still publishing pre-release info to interested users.

Each version URL is a real WordPress page in the sitemap. The base template page is noindex'd so only release pages compete in search. This means /release/v4-12-0/ ranks for queries like '[product] 4.12 release notes' or 'audit log export released', which is exactly the long-tail traffic that pays off for SaaS sites with active product development.

Add a 'security' or 'cve' array column for releases that include security fixes. Render it through a list mapping inside a security advisory section of the template, with each entry surfacing severity, CVE ID, and affected versions. Some teams also maintain a separate page group for /security/{cve}/ URLs cross-linked from the release pages, which gives security researchers and customers a direct path to advisory detail.

Yes. Each release page has a stable URL, and you can add anchor IDs in the base template per change category — #breaking-changes, #new-features, #fixes. The list mapping output gets wrapped in those sections automatically. Support docs and engineering blog posts can link to /release/v4-12-0/#breaking-changes for precise context, which is much more durable than referencing 'the changelog' generically.