Release notes and changelog

Release notes are the dated, first-party record of a product change: what shipped, who it affects, what behaves differently, and what a user must do next. A changelog is the chronological collection of those entries. The format is a retention tool before it is a traffic asset; customers use it to plan work and avoid surprises.

The governing rule is consequence before celebration. A release may be exciting to the team, but the reader first needs to know whether their workflow, integration, data, permissions, price, or compatibility changed. State that consequence in plain language, then explain the capability. Within the SEO post types system, release notes are support content at the retention stage; their value comes from permanent records that are never silently rewritten.

Questions it answers

A complete release-note entry answers the questions a current user asks after seeing a product change or encountering unfamiliar behavior:

• What changed, and on which release date or version did it change?
• Is the change available now, rolling out gradually, in beta, or limited by plan, region, platform, or account type?
• Who is affected, including administrators, end users, developers, partners, or a defined integration?
• What was the previous behavior, and what is different now?
• Does the user need to migrate, update settings, reauthorize access, retrain colleagues, or take no action?
• Is the change breaking, deprecated, reversible, security-sensitive, or likely to alter stored data?
• Where are the updated instructions, technical reference, known limitations, and support route?
• How can a reader verify that the new behavior is active in their account?

Do not make readers infer impact from labels such as “improved,” “updated,” or “streamlined.” “Exports are improved” is promotional but unverifiable. “CSV exports now include the applied country and model filters in two new columns; existing columns and order remain unchanged” defines the observable change and its compatibility boundary.

When to use this post type

Use release notes when an event has shipped or has a firm availability state and creates a user-visible difference worth preserving in product history. search intent is usually navigational or informational: readers search a product plus “release notes,” a version number, a changed feature, a deprecation, or an unfamiliar interface label. Do not use the format as a promise backlog, a general announcement feed, or a substitute for task documentation.

A change does not need a new interface to qualify. API behavior, retention, calculations, authentication, formats, limits, defaults, billing, and accessibility can all require an entry. An internal refactor with no observable consequence does not.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Best for these business types

The ranking reflects the need to maintain a dated public contract with existing users.

1. SaaS . The strongest fit because continuously delivered interfaces, APIs, permissions, integrations, and plan limits can change between customer visits. Entries should include rollout state, affected plans, administrator impact, and documentation links.
2. Marketplaces . High value because one release can affect buyers, sellers, moderators, payout recipients, or partners differently. Segment impact and avoid presenting a participant-specific change as universal.
3. Ecommerce . Useful for account, checkout, subscription, returns, loyalty, delivery, and merchant-tool changes. Separate storefront customer impact from operator or integration impact, especially around payments and order states.
4. Manufacturers and industrial suppliers . Important for firmware, control software, connected equipment, technical portals, and specification revisions. Version, model compatibility, safety boundaries, and rollback availability must be explicit.
5. Finance, fintech and insurance . Valuable but review-intensive because calculation, eligibility, disclosure, authentication, and data-handling changes may have regulatory consequences. Record jurisdiction, approval, effective date, and superseded behavior.
6. B2B services . Selectively useful when the service includes a maintained platform, methodology, dataset, client portal, or standard deliverable. Ordinary company news belongs elsewhere unless it changes the customer contract or workflow.

Search intent

Release-note demand is often low-volume and high-specificity. Queries include a product name with “changelog,” “latest version,” “what changed,” “new dashboard,” an API version, an error introduced after an update, or a deprecation date. The searcher is not asking for a broad product pitch. They want an authoritative timestamp and enough detail to make a decision.

The useful result shape begins with product + version or date + change + impact. Put these facts in the title, opening summary, headings, and metadata without forcing every minor entry onto its own indexable URL. Stable anchors let support teams and AI answers cite one entry; dedicated pages are warranted when a release has substantial migration work, distinctive demand, or several related changes.

Release notes are an underrated freshness signal because they expose real change at the pace it occurs. This does not justify changing dates to appear active. The entry date, current documentation, product behavior, and migration guidance must agree.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Page structure

Word bands set emphasis, not quotas. Preserve the same field order so readers can scan small fixes and breaking releases alike.

Group changes with stable labels such as Added, Changed, Fixed, Deprecated, Removed, Security, but never let a label replace the explanation. “Fixed: exports” is not a useful record. Each item must name the prior symptom or limitation, the new observable state, affected scope, and any required action.

Required elements

Position is part of risk control: a migration warning shown after the feature celebration arrives too late.

Frontmatter and structured data

Follow the frontmatter specification . This playbook page uses entity = "post-type-release-notes". A produced changelog should use a stable product-and-stream value such as entity = "atlas-cloud-release-notes"; an individual release may use entity = "atlas-cloud-2026-08". Do not use a campaign slogan or mutable release title as the identifier.

Use schemaType = "Article" for an individual release-note page. If the site exposes an index as a distinct entity, CollectionPage can describe that index while each material entry remains a visible dated item. Add FAQPage only when the FAQ is visible and supported by the implementation. Do not use HowTo merely because migration instructions contain steps, and do not mark a product as newly released when the page only corrected wording.

Store release date separately from publication and modification dates. Recommended fields include product, stream, version, status, releasedAt, platforms, plans, regions, affected roles, breakingChange, actionRequired, deprecationDate, owner, canonical URL, and documentation targets. For a staged rollout, keep one release date and state the window in visible copy.

Full example

The fictional example below demonstrates one material release. It keeps the migration consequence ahead of the feature summary and uses a stable version URL.

+++
title = "Atlas Cloud 4.8 Release Notes — 27 August 2026"
seoTitle = "Atlas Cloud 4.8 Release Notes: Export API Migration"
entity = "atlas-cloud-4-8"
keywords = [ "Atlas Cloud 4.8", "Atlas release notes", "export API v2", "Atlas changelog", "export migration", "Atlas product updates" ]
description = "Atlas Cloud 4.8 adds saved export views and API v2, explains the v1 deprecation deadline, and gives administrators a tested migration and validation path."
type = "academy"
date = "2026-08-27 10:00:00"
schemaType = "Article"
product = "Atlas Cloud"
version = "4.8"
releaseStatus = "rolling-out"
releasedAt = "2026-08-27"
platforms = [ "web", "API" ]
affectedRoles = [ "workspace administrator", "integration owner" ]
breakingChange = true
deprecationDate = "2026-10-15"
+++

# Atlas Cloud 4.8 release notes

Atlas Cloud 4.8 began rolling out on 27 August 2026. It adds saved export views and Export API v2. Workspace members can use saved views without changing existing exports. Integration owners using API v1 must migrate before 15 October 2026; after that date, v1 export requests will return an unsupported-version response.

## Action required: migrate Export API v1

**Who is affected:** integrations that send requests to `/api/v1/exports`. Dashboard exports and API v2 clients are not affected.

**What changes:** v2 requires an explicit `format` value and returns the export job identifier in `data.id`. The file columns do not change unless a saved view selects a different field set.

**Deadline:** complete migration and validation before 15 October 2026. Existing v1 requests continue to work until then.

1. Create a test request against the v2 endpoint with the same filters as a current v1 request.
2. Add the required `format` value and read the job identifier from `data.id`.
3. Compare row count, field set, timezone, and a known record between the old and new files.
4. Update production only after the comparison passes. Keep the previous configuration available until the first scheduled production export succeeds.

If the test does not match, leave the production integration on v1 and send support the sanitized request ID, timestamp, timezone, and field mismatch. Do not include an access token.

## Added: saved export views

Workspace administrators can save a named set of fields, filters, sorting, and file format. Members with export permission can reuse the view; saving a view does not grant access to records they could not already see.

To verify availability, open **Exports → Views** and look for **Save current view**. The control may take up to three days to appear during rollout. It is included on Standard and Enterprise plans in all regions.

## Fixed: country filter labels in CSV files

CSV exports now use the visible country name in the filter-summary column instead of the internal two-letter value. This changes the summary label only; filtered records and existing data columns are unchanged.

## Known limitations

Saved views cannot yet be transferred between workspaces. A deleted field is removed from the view the next time it runs, and the export history records that omission.

## Updated resources

- Export API v2 migration guide
- Export API reference
- Export permissions documentation
- Export troubleshooting

The example names a tested compatibility boundary, distinguishes rollout from release date, and gives readers a way to verify access.

Design gallery

Keep the same release facts in every layout variant so design review tests hierarchy, not different editorial decisions.

Quality checklist

A release note is ready only when every applicable statement is true:

• The title and opening identify the product, date or version, principal change, and affected audience.
• Availability is precise: shipped, rolling out with a window, beta, opt-in, plan-limited, region-limited, postponed, or withdrawn.
• Every entry explains observable before-and-after behavior instead of relying on “improved,” “enhanced,” or “fixed.”
• Added, changed, fixed, deprecated, removed, and security labels are applied consistently.
• Breaking changes appear before promotional benefits and state the affected scope, deadline, failure mode, replacement, migration, validation, rollback or support route.
• Dates distinguish release, publication, material modification, deprecation, and removal.
• Version identifiers, endpoint names, menu labels, plans, regions, and platform scope have been verified against the shipped state.
• The reader can tell whether action is required and how to confirm completion.
• Current documentation reflects the new behavior and links back to the relevant release where history matters.
• Screenshots have a capture date or version and a text equivalent for the controls or states they show.
• The archive provides stable URLs or anchors, newest-first browsing, and a way to reach older entries.
• Frontmatter FAQ answers and visible FAQ answers match exactly, and analytics distinguish browsing from migration or product action.

Common mistakes

Writing campaign copy instead of a record. “We are thrilled to transform your workflow” delays the fact. Lead with the shipped behavior, audience, availability, and action; put narrative in a separate launch announcement.

Burying breaking changes. A migration deadline below screenshots and benefits creates avoidable failure. Put the warning first and make it independently understandable.

Calling a rollout a launch everywhere. If only some accounts have access, say rollout and give the expected window. Users lose confidence when instructions describe a control they cannot yet see.

Using “bug fixes and improvements.” This hides affected behavior and prevents users from recognizing that their problem was resolved. Name the symptom, scope, and new state unless security disclosure requires restraint.

Moving dates for freshness. A typo correction does not make an old release new. Preserve releasedAt, record a material correction separately, and use lastmod only when the visible record changed meaningfully.

Duplicating current instructions. A long setup procedure will drift in two places. Summarize the changed step in the release note and let maintained documentation own the full current workflow.

Internal linking

Good internal linking makes the changelog the historical layer of product knowledge. Link from current documentation when a transition explains changed behavior. Link from the release to exact documentation, migration, troubleshooting, policy, or compatibility guidance where the user needs it.

Use one canonical record for each material change. A launch post, feature page, or support answer can cite it; none should copy it. Archive navigation should connect adjacent releases and the index. For deprecations, link the old entry to its replacement and the migration guidance back to the notice.

How to measure results

Measure whether users discover the right record, understand impact, complete required action, and need less clarification. Raw pageviews are not the goal: a small fix may serve its purpose with little traffic.

Use prompt tracking for product-plus-version questions, changed feature names, deprecation dates, and “latest update” wording. Use source and citation intelligence to inspect whether AI answers cite the canonical entry and preserve availability, affected scope, deadline, and required action. The AmICited Cockpit can place release-related visibility and cited URLs beside organic landing activity and selected product events.

Before publishing, record the affected audience, rollout window, support volume, migration baseline, target queries and prompts, and the event that proves success. Review:

• impressions and visits for product, version, feature, deprecation, and changelog queries;
• AI citations that reproduce the correct release date, status, compatibility boundary, and action;
• entry-level anchor or page views rather than changelog-index views alone;
• clicks into updated documentation, migration, troubleshooting, or verification paths;
• migration starts, validation completions, and remaining legacy usage where privacy-safe telemetry exists;
• support contacts caused by unclear scope, missing rollout access, or undocumented behavior;
• stale answers after a correction, withdrawal, superseding release, or deadline change.

Follow how we measure results to separate discovery, citation, engagement, task completion, retention, and business outcomes. Annotate launches, incidents, campaigns, and mandatory migrations before interpreting movement. A spike in traffic may indicate confusion, and a cited answer is harmful if it omits the breaking-change deadline.

FAQ

Frequently asked questions