Nuxas4.6.2
Get Nuxas
Content Editing

Managing Static Pages

A complete, beginner-friendly guide to creating, reading, updating, and deleting static pages in Nuxas. Learn how to add About pages, Privacy policies, Terms of Service, and any other page your site needs.

Managing Static Pages

In the previous chapter, we managed products. Now we will manage static pages — pages like About, Privacy, Terms of Service, and any other page that is not a blog post, a product, or part of the main site structure.

Static pages are the simplest content type in Nuxas. They have fewer fields than blog posts and products, and they do not have a gallery or a purchase URL. But they are just as important: they build trust, satisfy legal requirements, and answer common questions.

This chapter walks you through the entire lifecycle of a static page.

Where Static Pages Live

All static pages live in content/pages/. Each page is a separate Markdown file. The filename becomes the URL slug for the page. For example:

  • content/pages/about.md becomes /about
  • content/pages/privacy.md becomes /privacy
  • content/pages/terms.md becomes /terms

Filenames should be lowercase, with hyphens instead of spaces. Keep them short and descriptive.

Note: Nuxas rewrites the URL of every page in content/pages/ from /pages/[slug] to /[slug]. This is done through a Nuxt configuration called pages:extend. You do not need to do anything — the rewrite is automatic.

Understanding the Static Page Frontmatter

Every static page starts with a block of YAML between two --- lines. This is the frontmatter. It defines the page metadata: the title, description, heading, and optional sections like stats, pillars, and team.

Here is a complete example of a static page frontmatter (from content/pages/about.md):

---
title: About NuxtSass Starter — Engineering Ethos Behind the Nuxt 4 SaaS Template
description: Discover why we built NuxtSass Starter, the production-grade Nuxt 4 SaaS template. Idiomatic Nuxt code, zero bloat, WCAG AA accessibility, and a workflow designed for founders who ship.
tag: Engineering Ethos
heading: Crafted for Builders Who Respect Nuxt Craftsmanship
intro: We built NuxtSass Starter because we were exhausted by bloated starter kits that required two weeks of deleting code before you could start building.
stats:
  - value: 90+
    label: Lighthouse Score
  - value: 14ms
    label: Average TTFB
  - value: 45+
    label: Pre-Built Composables
  - value: 1,200+
    label: Active Founders
pillarsTag: Guiding Principles
pillarsTitle: The Four Pillars of NuxtSass
pillars:
  - icon: check
    title: "1. Nuxt Idiomatic"
    desc: Zero invented abstractions. We write composables the way the Nuxt team designed them.
  - icon: slash
    title: "2. Zero Hidden Bloat"
    desc: No monolithic runtime baggage. Every package included has a specific, documented purpose.
  - icon: shield
    title: "3. Accessibility First"
    desc: Full keyboard accessibility, contrast standards, and proper ARIA semantics.
  - icon: star
    title: "4. Production Rigor"
    desc: Tested against real payment failure edge-cases and multi-tenant schema isolation.
teamTag: Core Maintainers
teamTitle: Engineered by Practitioners
teamDesc: Meet the engineers maintaining and constantly updating the codebase.
team:
  - initials: AV
    name: Alex Vance
    role: Architecture & Nitro Engine
    bio: Former full-stack lead at edge cloud startups; 8 years building production Vue and Nuxt apps.
  - initials: EK
    name: Elena Kostas
    role: Security & Billing Systems
    bio: Stripe certified developer specializing in billing workflows, webhook resiliency, and authorization.
  - initials: SC
    name: Sarah Chen
    role: UI/UX & Design System
    bio: Design technologist passionate about WCAG AA accessibility, fluid typography, and zero-flicker themes.
---

Let us go through each field.

title

The page title. It appears in the browser tab and in search engine results.

Tip: Keep it under 60 characters for best SEO.

description

A one-sentence summary of the page. It appears in search engine results and social media previews.

Tip: Keep it between 120 and 160 characters.

tag

A small label that appears above the heading. Examples: Engineering Ethos, Legal, Support.

Tip: Use the tag to categorize the page. For an About page, "Engineering Ethos" is appropriate. For a Privacy policy, "Legal" is appropriate.

heading

The main heading of the page, rendered as an <h1>.

Tip: Make it descriptive and engaging. "Crafted for Builders Who Respect Nuxt Craftsmanship" is better than "About".

intro

A paragraph below the heading, explaining what the page is about.

Tip: The intro should be one or two sentences. The rest of the content goes in the body.

stats (optional)

An array of statistics. Each stat has a value (a short string like 90+ or 14ms) and a label (a short description). Stats are rendered as a grid of cards below the intro.

Tip: Use 3 to 4 stats. Too few and the section looks empty; too many and the numbers lose impact.

pillarsTag, pillarsTitle, pillars (optional)

A section of "pillars" — values, principles, or key features. Each pillar has an icon (one of check, slash, shield, star), a title, and a desc. Pillars are rendered as a grid of cards.

Tip: Use 4 pillars for best layout. Each pillar should be a distinct principle or feature.

teamTag, teamTitle, teamDesc, team (optional)

A section of team members. Each member has initials, name, role, and bio. Team members are rendered as a grid of cards with avatars.

Tip: Use 3 team members for best layout. Include real photos or initials.

Writing the Body

Below the frontmatter, the body of the page is written in Markdown. The body appears below the intro and any optional sections.

Here is an example body for an About page:

## Our Story: The Problem with Traditional Boilerplates

When Nuxt 4 released with its revolutionary Nitro engine, the developer experience for full-stack Vue applications took a massive leap forward. Yet, the ecosystem remained flooded with templates ported haphazardly from other frameworks, laden with outdated dependencies, obscure abstractions, and fragile state hydration.

In late 2024, our team of veteran Vue core contributors and indie founders decided to design a definitive starter: one that embraces idiomatic Nuxt patterns, adheres strictly to web standards, and stays lean enough to adapt to any business model.

## Why Most Nuxt Themes Fail Their Buyers

We audited dozens of commercial Nuxt themes before writing a single line of Nuxas. The same failures repeated:

- **Ports from React with no understanding of Vue's reactivity model.**
- **SEO as an afterthought.**
- **Bloated dependency trees.**
- **Zero accessibility.**

Nuxas was built as a direct answer to each of those failures.

## What We Believe

We believe a template should not obscure the framework. It should teach idiomatic patterns while removing friction. We believe performance and accessibility are not premium features — they are the baseline. And we believe you should own what you build, not rent it.

The body can be as long as you want. Use headings, paragraphs, lists, and internal links to make it readable.

Creating a New Static Page

If You Purchased the Code + Decap CMS Edition

  1. Open http://localhost:3000/admin.
  2. In the left sidebar, click Static Pages.
  3. Click New Static Page in the top right corner.
  4. Fill in the fields:
    • Title — the page title.
    • Description — a short summary.
    • Tag — a category label.
    • Heading — the main heading.
    • Intro — a paragraph.
    • Body — the page content in Markdown.
    • Stats — optional, add statistics.
    • Pillars — optional, add pillars.
    • Team — optional, add team members.
  5. Click Save in the top right corner.

The CMS will create a new file in content/pages/ with a slug derived from the title.

If You Purchased the Code Only Edition

  1. Open the content/pages/ folder in VS Code.
  2. Right-click the folder and choose New File.
  3. Name the file with a slug, e.g., privacy.md.
  4. Paste the frontmatter template at the top of the file.
  5. Fill in the fields.
  6. Write the body in Markdown below the frontmatter.
  7. Save with Ctrl + S.

Reading a Static Page

To view a static page on your local site, go directly to the page URL:

http://localhost:3000/about
http://localhost:3000/privacy
http://localhost:3000/terms

The page shows:

  • The tag, heading, and intro at the top.
  • The body in Markdown.
  • Stats (if defined).
  • Pillars (if defined).
  • Team (if defined).
  • A call-to-action band at the bottom (if defined in site.yml).

Updating a Static Page

If You Purchased the Code + Decap CMS Edition

  1. Open http://localhost:3000/admin.
  2. In the left sidebar, click Static Pages.
  3. Click the page you want to edit.
  4. Change any field or the body.
  5. Click Save.

If You Purchased the Code Only Edition

  1. Open the page file in content/pages/.
  2. Edit any field or the body.
  3. Save with Ctrl + S.

Deleting a Static Page

If You Purchased the Code + Decap CMS Edition

  1. Open http://localhost:3000/admin.
  2. In the left sidebar, click Static Pages.
  3. Click the page you want to delete.
  4. Click the three dots in the top right corner, then choose Delete.
  5. Confirm the deletion.

If You Purchased the Code Only Edition

  1. Open the content/pages/ folder in VS Code.
  2. Right-click the page file and choose Delete.
  3. Confirm the deletion.

A Complete Example: Privacy Policy

Here is a complete Privacy Policy page, ready to copy and adapt:

---
title: Privacy Policy — My SaaS
description: Our privacy policy explains what data we collect, how we use it, and how we protect it.
tag: Legal
heading: Privacy Policy
intro: Your privacy matters. This page explains what data we collect, how we use it, and how we protect it.
---

## What We Collect

We collect the minimum amount of data necessary to run our service:

- **Account information** — your name and email address, provided when you create an account.
- **Payment information** — processed by Stripe. We do not store your card details.
- **Usage data** — anonymous analytics about how you use the site.

## How We Use Your Data

We use your data to:

- Provide and improve the service.
- Send transactional emails (receipts, password resets).
- Respond to your support requests.

We do not sell your data. We do not share it with third parties except where required to provide the service (e.g., Stripe for payments).

## Your Rights

You have the right to:

- Access your data.
- Correct your data.
- Delete your data.
- Export your data.

To exercise any of these rights, contact us at [support@example.com](mailto:support@example.com).

## Changes to This Policy

We may update this policy from time to time. When we do, we will notify you by email.

_Last updated: January 2026._

This example has a complete frontmatter, a body with sections for what is collected, how it is used, rights, and changes. Copy it, change the values, and you have a Privacy Policy page.

What to Expect in the Next Chapter

In the next chapter, we will do a pre-push check — a set of things to verify before you push your code to GitHub and deploy to production. This is a short but important chapter. It will save you from embarrassing mistakes like broken links, missing images, or incorrect URLs.

See you in the next chapter.