Documentation Articles: Versioned Reference for Existing Users

A documentation article is a maintained reference for someone already using a product, API, service, device, or operating process. It answers a precise lookup question—what a setting does, which values a field accepts, what access is required, which version behaves this way, or where a limit applies—without making the reader pass through a marketing argument first.

Its contract is scope → prerequisites → current behavior → exact reference → exceptions → related task. The page succeeds when a user retrieves the right fact for the right version and role. Turning every interface label into a public URL does not help.

Questions it answers

The primary question is: “What does this product behavior mean in my version and context?” Supporting questions include:

• Does this page apply to my product, plan, role, region, platform, and version?
• What must already be true before I use this feature or reference this field?
• What are the accepted values, defaults, limits, formats, and side effects?
• Which behavior is current, and what changed from an earlier version?
• Which example demonstrates the rule without hiding important conditions?
• What should I read next if I need a procedure, diagnosis, or change history?
• Is this information safe and useful in public search, or does it require authenticated context?

When to use this post type

Use documentation when one stable page must support repeated lookup. The subject needs an authoritative owner, testable behavior, and a maintenance signal such as a release, API, plan, or interface change.

A page called “How to configure export fields” may still be documentation when its durable value is a field catalogue and users jump directly to individual parameters. Conversely, “Export your first report” is a how-to when the reader must follow a sequence and verify a downloaded file. Title grammar does not decide the format; the reader’s task and the answer shape do.

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

1. SaaS . The strongest fit because roles, plans, settings, integrations, APIs, data models, and release cadence produce exact reference needs. Documentation should distinguish interface behavior from API behavior and user permissions from subscription entitlements.
2. Ecommerce . Strong for merchant administration, product feeds, payment rules, returns, integrations, and post-purchase use. Separate customer help from merchant documentation so a shopper does not land on an implementation reference.
3. Marketplaces . Strong where buyer, seller, provider, and administrator roles see different states. Every article must identify the actor because the same label can expose different controls or obligations.
4. Agencies . Useful for client portals, deliverable standards, recurring workflows, and shared tooling. Publish reusable client reference publicly only when it does not expose internal controls, credentials, or proprietary operating detail.
5. B2B services . Useful for onboarding systems, data handoffs, file specifications, approval states, and service portals. Avoid presenting a contractual commitment as a generic help-centre fact when terms vary by account.
6. Manufacturers and industrial businesses . Valuable for controls, software, compatibility, configuration, maintenance records, and technical parameters. Safety-critical material requires controlled review, explicit model applicability, and a route to the authoritative manual.

Search intent

Search intent is the result a person expects from a query. Documentation intent is usually navigational plus informational: the searcher knows the product or object and wants an exact fact, such as “Northstar export retention,” “Northstar status values,” or “Northstar API page size.” Brand, feature, error-free task language, version, and platform often appear together.

The ideal result opens close to the answer. Use descriptive headings, stable anchors, accepted values, and version qualifiers. An extracted statement must preserve its condition: “On Team and Enterprise plans, completed exports remain available for 30 days.”

Public documentation should rank when it answers a durable question without revealing account data: supported formats, public API fields, compatibility, limits, configuration meaning, and documented behavior.

Documentation should not rank when it mirrors one UI label, duplicates a current page, covers an obsolete version with no continuing need, exposes sensitive detail, or needs private account context. Use authenticated help, in-app guidance, noindex, consolidation, or a clear archive state instead. Search demand never justifies publishing secrets or exploit paths.

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 are production controls, not minimum quotas. A narrow field reference may be shorter; a versioned feature reference may need more space because applicability and exceptions prevent costly mistakes.

Most substantial documentation articles fall between 1,500 and 2,800 words. Add detail only where it prevents ambiguity: scope, prerequisite, value, default, side effect, exception, or version change.

Required elements

Reference readers scan. Position the applicability information before the reference so a technically correct value is not applied to the wrong plan or release.

Frontmatter

Follow the frontmatter specification . On this post-type specification, entity = "post-type-documentation-article". On a produced documentation page, use a stable product-object value such as northstar-scheduled-export-settings, not a promotional phrase such as effortless-reporting and not a version number that would force a new identity after every release.

Use schemaType = "Article". schema markup must describe the visible page; do not select HowTo merely because one example contains three actions. Add FAQ structured data only when visible questions and answers match it exactly. API reference or software-specific semantics may be represented elsewhere in the site’s data model, but a more specific schema type should not be invented in frontmatter without template support.

Store the fields the maintenance system can enforce: product area, plans, role, platform, version range, verified date, owner, and replacement URL. lastmod means behavior was reviewed, not that a typo was fixed. Preserve the canonical URL across compatible releases.

Full example

This fictional analytics example demonstrates a reference page, not a complete export procedure.

# Scheduled export settings

Scheduled exports create a CSV or JSON file from a saved report at a fixed UTC time and deliver it to an approved destination. They are available to Editors and Administrators on Team and Enterprise plans. This reference applies to Northstar Analytics web app 6.4 and was verified on 27 August 2026.

## Before you use this reference

You need an existing saved report, an enabled destination, and Editor or Administrator access. A Viewer can download an existing export but cannot create or change a schedule. Destination administrators may impose additional retention or file-size limits.

## Settings reference

| Setting | Accepted value | Default | Effect and constraints |
|---|---|---|---|
| Name | 1–80 characters | Report name | Identifies the schedule; changing it does not rename prior files. |
| Format | `csv` or `json` | `csv` | CSV uses the report's visible column order. JSON uses stable field keys. |
| Run time | `HH:MM` in UTC | `08:00` | Daylight-saving changes do not move the UTC run time. |
| Include empty rows | On or off | Off | Available only for tabular reports; ignored for summary reports. |
| Retention | 1–30 days | 7 days | Existing files expire independently of the schedule that created them. |

## Behavior and boundaries

A schedule reads the saved report configuration when the run begins. Editing the report therefore changes future files but not files already generated. Pausing a schedule prevents new runs; it does not delete retained files. Deleting the destination disables delivery and places the schedule in `Needs attention`.

## Example

For a daily CSV needed at 09:00 in Bratislava during standard time, set the UTC run time to `08:00`. Review the time when daylight-saving rules change because schedules remain fixed to UTC.

Invalid example: entering `Europe/Bratislava` in the run-time field. The field accepts a UTC time, not a timezone identifier.

## Version differences

- Version 6.4: JSON exports use stable field keys; the displayed column label no longer becomes the key.
- Versions 6.1–6.3: JSON keys follow displayed column labels. Existing integrations should be checked before upgrade.
- Before 6.1: scheduled JSON export is unavailable. Use CSV or upgrade to a supported version.

## If an export does not arrive

Do not add speculative fixes here. Open the “Scheduled export did not arrive” troubleshooting guide, which checks schedule state, destination authorization, file limits, and service incidents in diagnostic order.

## Related tasks

- Create your first scheduled export — ordered setup and success check
- Troubleshoot a missing scheduled export — symptom-led diagnosis
- Northstar Analytics 6.4 release notes — behavior changes and migration note

## Verification record

Verified against web app 6.4 by the Reporting product owner on 27 August 2026. Review when permissions, formats, retention, scheduling, or destination behavior changes.

Design gallery

Use identical settings, limits, roles, and version facts across variants so design review measures retrieval speed rather than copy differences.

Quality checklist

A documentation article is ready only when every applicable statement is true:

• The opening names the exact object and gives the current behavior before background or benefits.
• Product, plan, role, region, platform, and version applicability are explicit where they change the answer.
• Prerequisites appear before settings or examples that depend on them.
• Every technical term is defined on first use, expressed through a familiar interface label, or linked to its canonical definition.
• Fields, values, defaults, units, formats, limits, and side effects come from an authoritative source or verified product test.
• Reference tables use consistent dimensions; blank cells do not hide unknown defaults or exceptions.
• Examples state the conditions that make them valid and include an invalid or boundary example when confusion is likely.
• Warnings appear before destructive, irreversible, security-sensitive, costly, or permission-changing behavior.
• Screenshots include a capture version and text equivalent; the image is not the only source of a value or instruction.
• Headings and anchors match the nouns users search for and remain stable for deep links.
• Material version differences state the affected range, current replacement, and migration consequence.
• The verified date reflects a behavioral review, and a named team or role owns the next review.
• Procedures, diagnosis, and release history link to canonical sibling pages instead of being duplicated incompletely.
• Public indexing is intentional; obsolete, duplicate, private, and security-sensitive material has an appropriate search treatment.
• FAQ records match visible answers, and the CTA respects a support-stage reader’s next task.

Common mistakes

Writing a feature landing page for an existing user. “Unlock powerful exports” delays the fact the reader needs. Lead with behavior, applicability, and constraints; benefit copy belongs only where it clarifies purpose.

Turning every task into documentation. A 20-step setup buried beneath a field list serves neither lookup nor completion. Split the ordered procedure into a how-to and link it from the relevant prerequisite or related-task section.

Publishing one page per interface label. Thin pages overlap and multiply maintenance. Group fields around a stable product object unless one setting has distinct behavior.

Using “latest” as a version. Latest changes. State the tested release, supported range, platform, and verification date, then update them through the release process.

Keeping old and new pages indexable without a boundary. Consolidate compatible behavior; otherwise label the old version, link to the current page, and control indexing intentionally.

Hiding prerequisites inside errors. If only Administrators can change a field, say so before the reference. Do not make a Viewer discover the role boundary after following an example.

Copying screenshots instead of behavior. A capture is evidence of one interface state, not the specification. Write labels, paths, values, and conditions in accessible text and record the captured version.

Faking freshness. Changing the date without retesting the behavior makes the page look safer while increasing risk. Update the verification record only after its owner checks the applicable claims.

Letting public search expose internal detail. Internal escalation paths, secrets, customer identifiers, exploit instructions, and unannounced behavior do not become safe because they reduce support effort. Separate public help from authenticated and internal knowledge.

Internal linking

Link upward to SEO post types when the author may need a different answer shape. Link from a documentation prerequisite to the canonical how-to only when a reader must complete that task first. Link from an error state to troubleshooting rather than inserting a generic fix list. Link from a version difference to the release event when the change history adds context; release notes should link back to the current documentation as the durable source of truth.

Organize links around product objects and reader state. Keep a specific link beside the statement that creates the next question instead of relying on a long related-articles list.

One canonical current page should own stable behavior. Keep version pages only for materially different behavior users still need, and make that distinction explicit. Use stable anchors such as #retention, not #table-2.

How to measure results

Measure whether users retrieve the correct answer for their version. Traffic alone is weak evidence: a surge can reflect a broken product or obsolete answer.

Record target queries, ranking URL, indexability, supported versions, support searches, related-task exits, and a suitable product event. Then review:

• search impressions and qualified visits for product-object, field, limit, syntax, role, and version queries;
• internal search refinements, zero-result searches, and repeated searches that reveal missing terminology;
• engagement with anchored sections rather than undifferentiated time on page;
• clicks to the correct setup, troubleshooting, release, or support destination;
• support contacts whose question the page should answer, segmented by version and role where privacy permits;
• citations that preserve the value together with its plan, version, unit, or prerequisite;
• obsolete URLs still ranking or being cited after consolidation or retirement;
• documentation changes caused by releases, interface changes, policy changes, and recurring support cases.

Use prompt tracking for branded lookup questions and version variants. Use source and citation intelligence to see which URL an answer engine cites and whether its summary preserves conditions. Open the AmICited Cockpit to compare cited URLs, visibility, organic landing activity, and the chosen product or support event over the same observation window.

Follow how we measure results to separate discovery, representation, engagement, task progression, and retention. Annotate releases and incidents before interpreting movement. A zero-click answer works only when it preserves the current value and its conditions.

FAQ

Frequently asked questions