Policy or legal page

A policy page publishes an organization’s own rules, commitments, rights, and procedures: terms of service, privacy notices, return policies, or shipping policies. It explains what applies, to whom, from when, and what happens next while preserving the governing text.

Purpose: pair a plain-language route with approved binding text, effective dates, contact routes, and a traceable change history.

Reader question: “What are the rules for this transaction or relationship, and what can I do if I need to exercise a right, make a return, or resolve a problem?”

This SEO post types format is a trust and decision page. Legal review determines the substance; content design makes it findable and understandable without changing its meaning.

Questions it answers

The opening should identify the policy before asking the reader to interpret it. Answer:

• What policy is this, which organization publishes it, and which products, services, sites, transactions, or people does it cover?
• Is this page the current version, and when was it published, last reviewed, and made effective?
• Which parts are binding text, which parts are a plain-language summary, and what controls if they differ?
• What does the organization promise, permit, require, restrict, collect, share, ship, refund, or refuse?
• Which eligibility rules, time windows, territories, exclusions, fees, or exceptions change the outcome?
• What must the reader do, what evidence is needed, where is the request sent, and how long does the process normally take?
• How will material changes be communicated, and where can a reader inspect prior versions?
• Which contact route handles policy questions, rights requests, complaints, returns, or accessibility needs?

Write these answers for the actual policy. “Contact us for details” is inadequate when the policy controls a purchase, account, or data decision.

When to use this post type

Use this type when the organization is declaring its own rules or practices and readers may rely on those declarations. The source of authority is the organization, its agreement, and applicable law—not an editorial explanation of someone else’s regime.

Do not wrap copied boilerplate for search traffic. If the organization cannot name the owner, scope, version, process, and review trigger, the page is not ready.

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

Every organization needs some governance pages. The ranking reflects how directly a published policy affects a reader’s decision and how often operational details change the outcome.

1. Ecommerce . Returns, refunds, exchanges, cancellations, shipping destinations, delivery estimates, duties, damaged items, and final-sale exclusions can determine whether a shopper completes a purchase. Keep product-page summaries synchronized with the canonical policies.
2. SaaS . Terms, acceptable use, privacy, subprocessors, security commitments, renewals, cancellation, and data handling shape procurement and account decisions. State whether a policy covers visitors, trial users, customers, administrators, or end users.
3. Marketplaces . Buyer, seller, platform, payment, moderation, dispute, and identity responsibilities overlap. Separate the rules by participant and name which party performs each action.
4. Finance, fintech, and insurance . Privacy, eligibility, fees, complaints, disclosures, and account terms can carry significant consequences. Jurisdiction, licensed entity, product, and document version need to remain visible.
5. Healthcare and pharmacy . Privacy, consent, fulfillment, substitution, cancellation, and complaint routes require careful role and safety boundaries. Avoid mixing patient information with general customer-service forms.
6. Travel and hospitality . Cancellation windows, deposits, no-shows, changes, refunds, local taxes, accessibility, and third-party bookings are decision-critical. Explain dates and timezones with concrete examples.
7. Local services . Deposits, cancellations, service areas, arrival windows, warranties, and property access often affect booking. A concise, local-scope policy is more useful than enterprise boilerplate.

Search intent

Policy searches are usually navigational or decision-support queries: “[brand] return policy,” “[product] cancellation terms,” “[store] ships to Canada,” or “[company] privacy request.” The reader wants a dependable rule, deadline, eligibility condition, or contact route. The best result is the current canonical policy, not an article about it.

Search snippets and AI answers tend to extract the shortest apparent rule. That creates risk when a time window is separated from its start event, territory, condition, fee, or exception. Keep the qualification attached: “Unused standard items may be returned within 30 calendar days after confirmed delivery” is safer than “30-day returns” followed much later by exclusions.

Do not optimize away formal terminology that has a defined meaning. Pair it with plain language on first use, preserve the definition in the binding text, and make dates unambiguous. “Effective 1 September 2026” is clearer than “effective next month,” and “calendar days after delivery” is clearer than “within 30 days.”

Stay Updated on AI Visibility Trends

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

Email address

Subscribe

Page structure

The summary comes first for orientation; the binding text follows because enforceability cannot depend on a summary. Word bands are controls, not padding targets.

Required elements

Each element prevents hidden scope, stale terms, detached exceptions, or an unclear action route.

Frontmatter

Follow the frontmatter specification . For the playbook specification itself, use entity = "post-type-policy-page". For a produced policy, use a stable, scoped value such as acme-return-policy-us or acme-privacy-notice-customers-eea; do not use a generic value such as legal that collapses several documents.

Use schemaType = "WebPage" as the primary schema type. Add FAQPage only when the page visibly renders the identical questions and answers and current platform guidance supports the implementation. An organization’s privacy notice is not Legislation, and there is no need to invent a LegalDocument type. Represent the organization, publisher, canonical URL, language, and dates accurately; do not mark a cosmetic edit as a new effective version.

Useful fields include policyOwner, approvedBy, publishedDate, effectiveDate, lastReviewed, jurisdictions, appliesTo, version, and archiveUrl. They do not replace visible text; effective date and scope must remain readable without scripts or structured data.

Full example

This fictional return policy demonstrates the two-layer approach. It is a content model, not reusable legal language.

+++
title = "Northstar Goods Return and Refund Policy"
entity = "northstar-goods-return-policy-us"
type = "policy"
schemaType = "WebPage"
publishedDate = "2026-08-15"
effectiveDate = "2026-09-01"
lastReviewed = "2026-08-15"
version = "3.0"
jurisdictions = [ "United States" ]
appliesTo = [ "Purchases from northstargoods.example" ]
policyOwner = "Customer Operations"
approvedBy = "Legal"
+++

# Return and refund policy

This policy applies to purchases made directly from Northstar Goods in the United States. Version 3.0 is effective 1 September 2026 and replaces version 2.2.

## Plain-language summary

Most unused standard items can be returned within 30 calendar days after confirmed delivery. Start the return online before sending the item. Custom-made items and final-sale items are not eligible unless they arrive damaged, defective, or different from the order. The full policy below controls if this summary and the full text differ.

## Check eligibility

| Item or situation | Request deadline | Condition | Outcome |
|---|---|---|---|
| Standard item | 30 calendar days after confirmed delivery | Unused, with included parts | Refund to original payment method after inspection |
| Damaged or incorrect item | 7 calendar days after confirmed delivery | Photos and order number requested | Replacement or refund after review |
| Custom-made item | Not ordinarily returnable | Eligible only if damaged, defective, or incorrect | Review required |
| Final-sale item | Not ordinarily returnable | Statutory rights remain unaffected | Review required |

## Start a return

Submit the return form with the order number, item, reason, and requested outcome. We send an acknowledgment and instructions to the email used for the order. Do not ship an item until return instructions are issued; an untracked parcel sent elsewhere may not be matched to the order.

## Refund timing

After the returned item is received and inspected, we notify you whether the return is accepted. An approved refund is sent to the original payment method. Your payment provider controls when the credit appears. Original delivery charges and return shipping are refunded only where this policy or applicable law requires it.

## Exceptions and statutory rights

Nothing in this policy limits rights that cannot legally be excluded. Contact Customer Operations if an item is unsafe, damaged, defective, or not as described, even when the ordinary return window has ended.

## Changes to this policy

- 1 September 2026, version 3.0: clarified when the 30-day window starts and added the damaged-item route.
- 10 January 2026, version 2.2: clarified the refund destination.

## Contact

Use the return form for a return request. For help accessing the form or requesting this policy in another format, contact Customer Operations by the published support route.

The example keeps the starting event beside each deadline, separates ordinary returns from non-excludable rights, and avoids promising bank-processing time the merchant cannot control. Counsel and operations must replace every fictional rule and approve both layers.

Design gallery

One return policy lets reviewers compare layouts without changing the legal content.

Quality checklist

• The page names one policy, one publishing organization, and the covered relationship without using “all users” as a substitute for scope.
• The current version, publication date, effective date, and last-reviewed date are visible and not treated as synonyms.
• A labeled plain-language summary surfaces the main decision rules and states whether the full text controls.
• Every deadline names its starting event, unit, timezone where relevant, and exceptions.
• Binding rules retain their conditions, exclusions, fees, remedies, and non-excludable rights in the same section.
• Definitions are necessary, consistently capitalized, and understandable on first use.
• The operational process can fulfill every promise the text makes, including response routes, refund methods, and access requests.
• Policy, checkout, product, account, support, and email summaries use the same approved rule source.
• Material changes have an owner, approval record, notice method, effective date, and archived version where required.
• Contact routes work without requiring unrelated marketing consent and include an accessibility alternative.
• Structured data matches visible content and does not assert a legal type the page does not have.
• Counsel or the designated legal reviewer approves the binding language before publication.

Common mistakes

Treating the summary as harmless marketing copy

A prominent “30-day returns” promise shapes a purchase even if the binding text excludes the item. Generate summaries from the approved rule source and keep decisive qualifications attached.

Hiding the effective date in the footer

Readers and reviewers need to know which version governed an event. Show the effective date beside the title, preserve the transaction date, and retain required versions.

Copying boilerplate the operation cannot honor

A template may promise a channel, workflow, region, or refund method that does not exist. Map each clause to an owner and tested process before publication.

Using one page for unrelated policies

Combining privacy, terms, returns, and shipping creates a long document with several audiences and change cadences. Separate canonical policies, then provide concise navigation between them.

Announcing every edit as a new policy

Typographic corrections and material changes are not equivalent. Define the threshold with counsel, log the change, and follow existing notice and consent commitments. Never hide reduced rights behind a fresh timestamp.

Letting FAQs become shadow terms

If an FAQ changes eligibility or a remedy, reconcile the approved policy and operating process before publishing the answer.

Internal linking

Link into a policy at the decision point: cart, checkout, signup, account settings, request form, footer, product restrictions, or a relevant support answer. Use anchors that name the destination and task, such as “return and refund policy,” rather than “learn more.” Consequential terms should not require a reader to search the site.

Link out only when the destination helps the reader act or verify context:

• Send a summary to the exact governing section, not merely the top of a long document.
• Connect privacy notices to rights-request and contact routes; connect returns to the return workflow; connect shipping to destination and tracking help.
• Connect related policies through a small internal link module with clear boundaries between terms, privacy, shipping, returns, cookies, and accessibility.
• Keep commercial CTAs out of complaint and rights-request paths unless the reader has completed the task and marketing consent is genuinely separate.

Assign one canonical owner for each rule. Other pages may summarize it, but the policy owns the approved text, effective date, and history. Flag conflicting numbers, regions, fees, and deadlines.

How to measure results

Success is not raw traffic. Readers should find the current version, understand the applicable rule, complete the correct process, and avoid unnecessary clarification without being blocked from legitimate help.

Use the measurement methodology to set a baseline before a rewrite and record the publication date, version, notice event, form change, and navigation change.

Segment by policy, version, jurisdiction, device, referrer, and task outcome. Review qualitative contact reasons alongside analytics; a lower contact rate is not positive if eligible people abandoned a broken form. Do not claim that page views prove consent, comprehension, legal compliance, or acceptance of terms.

Frequently asked questions

Is a policy page legal advice?

No. A published policy states an organization’s rules or practices, while this content specification explains how to structure that page. Qualified counsel should approve binding language, jurisdictional coverage, and consequential changes.

Should the plain-language summary be part of the binding terms?

Only if counsel intentionally drafts it that way. Otherwise, label the summary as an aid, state that the full policy controls, and make sure the summary never contradicts or silently narrows the binding text.

Can privacy, returns, shipping, and terms share one page?

Usually not. Each policy has a different audience, decision, owner, scope, and update trigger. Keep separate canonical pages and connect them through a small policy navigation module unless a genuinely short policy set remains easier to understand together.

What schema type should a policy page use?

Use WebPage as the primary type. Add FAQPage only when the same questions and answers are visibly rendered and the implementation follows current search-platform rules. Do not invent a legal-policy schema type or use Legislation for an organization’s own policy.

How should policy changes be communicated?

Show the effective date, preserve a concise change history, and use the notice method promised by the current agreement or required by applicable law. Material changes may need direct notice or renewed consent; page publication alone is not always sufficient.

Should old policy versions remain accessible?

Preserve them when contractual, regulatory, dispute, audit, or customer-support needs require a historical record. Mark every archived version clearly, remove it from ordinary navigation where appropriate, and point to the current version without rewriting the historical text.