Project Structure — Data and Content

A complete reference for Dax Pro's _data and content folders: metadata, navigation, footer configuration, homepage data, posts, services, pages, and tags. Everything you edit as a site owner lives in these two folders.

Two Folders That Run Your Site

Dax Pro has a small number of folders. Of those, only two matter to a site owner:

  • _data/ — site-wide configuration. Metadata, navigation, footer.
  • content/ — all the content on the site. Homepage, about, contact, blog posts, services, tags.

    • If you open nothing else, open these two. Every text you see on your rendered site comes from a file in one of these folders. If you can edit YAML and Markdown, you can run the entire site without ever opening a template or touching C#.

    This chapter documents exactly what lives in _data/ and content/, how the folder structure maps to URLs, and what each file is responsible for. It does not cover templates or the DAX engine — those belong to the developer guide. This chapter is for the person running the site.

    The Full Project Directory at a Glance

    Before diving into the two folders, here is the complete project structure so you know where everything sits:

    dax-pro/

    ├── _data/              ← site configuration (this chapter)
    

    ├── content/            ← all content (this chapter)
    

    ├── templates/          ← layouts and partials (developer guide)
    

    ├── public/             ← CSS, JS, images (developer guide)
    

    ├── site/               ← generated output (gitignored)
    

    ├── Dax.csproj          ← C# project file
    

    ├── Program.cs          ← the DAX engine
    

    ├── README.md           ← quick start
    

    ├── LICENSE             ← commercial license
    

    ├── netlify.toml        ← Netlify deployment config
    

    └── vercel.json         ← Vercel deployment config

    The two folders this chapter covers are _data/ and content/. Everything else either belongs to the developer workflow (templates, public, Program.cs) or is a configuration file for deployment platforms (netlify.toml, vercel.json).

    Folder 1 — _data/

    The _data/ folder holds site-wide configuration. These are values that appear on every page of the site, not just one. If the value is in _data/, it is almost certainly rendered inside the navigation bar, the footer, or every page's .

    Dax Pro ships with three YAML files in _data/:

    _data/

    ├── metadata.yaml
    

    ├── nav.yaml
    

    └── footer.yaml

    YAML is the format. It is whitespace-sensitive, so indentation matters. Two spaces per level, never tabs. Quote string values that contain special characters or start with a symbol. The example files below show the correct syntax.

    _data/metadata.yaml — Site Identity and SEO

    This file describes the site itself. It is read by every page to generate the </code>, the meta description, the OpenGraph tags, and the JSON-LD schema. Search engines and social media platforms read these values. Get them right and every page inherits correct SEO; get them wrong and every page inherits the error.</p> <p>A complete <code>metadata.yaml</code> looks like this:</p> <pre><code>title: "Dax Pro" <p>description: "Enterprise .NET Static Site Generator & Decap CMS Architecture"</p> <p>url: "https://daxpro.axcora.com"</p> <p>icon: "/images/dax-primary-logo.webp"</p> <p>image: "/images/dax-primary-logo.webp"</p> <p>author: "Axcora"</p> <p>social:</p> <p> - name: "GitHub"</p> <p> url: "https://github.com/mesinkasir/dax"</p> <p> - name: "Gumroad"</p> <p> url: "https://creativitaz.gumroad.com/l/dax-pro"</p> <p> - name: "Fiverr"</p> <p> url: "https://www.fiverr.com/creativitas/design-your-website-with-progresive-web-application"</p> <p></code></pre></p> <p><strong>What each field does:</strong></p> <div class="table-responsive"><table> <thead><tr> <th>Field</th> <th>Purpose</th> <th>Example</th> <p></tr></thead></p> <tbody> <tr> <td><code>title</code></td> <td>Site name. Used in <code><title></code> tags, JSON-LD publisher, OpenGraph site_name.</td> <td><code>"Dax Pro"</code></td> <p></tr></p> <tr> <td><code>description</code></td> <td>Default meta description. Used when a page has no specific description.</td> <td><code>"Enterprise .NET Static Site Generator..."</code></td> <p></tr></p> <tr> <td><code>url</code></td> <td>The site's production URL. <strong>No trailing slash.</strong> Used for canonical links, sitemap, RSS, JSON-LD.</td> <td><code>"https://daxpro.axcora.com"</code></td> <p></tr></p> <tr> <td><code>icon</code></td> <td>Path to the favicon. Can be <code>.ico</code>, <code>.png</code>, or <code>.webp</code>.</td> <td><code>"/images/favicon.ico"</code></td> <p></tr></p> <tr> <td><code>image</code></td> <td>Default OpenGraph image. 1200×630 pixels is the standard for social sharing.</td> <td><code>"/images/og-default.jpg"</code></td> <p></tr></p> <tr> <td><code>author</code></td> <td>Site author name. Used in JSON-LD <code>author</code> and in RSS feed.</td> <td><code>"Axcora"</code></td> <p></tr></p> <tr> <td><code>social</code></td> <td>List of social profile links. Used in JSON-LD and future schema extensions.</td> <td>See example</td> <p></tr></p> <p></tbody></table></div></p> <p><strong>Important rules:</strong></p> <li><strong><code>url</code> must not end with a slash.</strong> <code>"https://example.com"</code> is correct; <code>"https://example.com/"</code> will produce <code>https://example.com//page/</code> in canonical links. This is a subtle bug that some analytics tools flag.</li> <li><strong><code>icon</code> and <code>image</code> must start with <code>/</code>.</strong> They are resolved relative to the site root. <code>/images/favicon.ico</code> is correct; <code>images/favicon.ico</code> will produce broken links on nested pages.</li> <li><strong>Quote all values.</strong> YAML does not require quotes for simple strings, but quoting them prevents issues with values that contain colons, hashes, or special characters. Dax Pro examples always quote.</li> <li><strong><code>social</code> is a list of dictionaries.</strong> Each item has a <code>name</code> and a <code>url</code>. Add as many as you need.</li> <h3><code>_data/nav.yaml</code> — Navigation Bar</h3> <p>This file defines three things: the brand wordmark displayed in the top-left corner, the navigation menu items, and the two call-to-action buttons on the right side of the navigation bar.</p> <p>A complete <code>nav.yaml</code> looks like this:</p> <pre><code>brand: <p> symbol: ".NET"</p> <p> name: "DAX"</p> <p> accent: "PRO"</p> <p>items:</p> <p> - title: "Home"</p> <p> mobile_title: "Home"</p> <p> url: "/"</p> <p> - title: "About"</p> <p> mobile_title: "About Dax Pro"</p> <p> url: "/about/"</p> <p> - title: "Services"</p> <p> mobile_title: "Enterprise Services"</p> <p> url: "/services/"</p> <p> - title: "Insights"</p> <p> mobile_title: "Technical Insights"</p> <p> url: "/posts/"</p> <p> - title: "Tags"</p> <p> mobile_title: "Architecture Tags"</p> <p> url: "/tags/"</p> <p> - title: "Contact"</p> <p> mobile_title: "Enterprise Contact"</p> <p> url: "/contact/"</p> <p>secondary:</p> <p> text: "Pricing"</p> <p> url: "/#pricing"</p> <p>cta:</p> <p> text: "Deploy Dax Pro"</p> <p> url: "/#contact"</p> <p></code></pre></p> <p><strong>What each section does:</strong></p> <p><strong><code>brand</code></strong> — the wordmark in the top-left. Dax Pro renders three pieces: a symbol badge (<code>.NET</code>), a name (<code>DAX</code>), and an accent (<code>PRO</code>). The accent is colored differently to highlight it. To change the brand, change these three values. There is no logo image here — this is text.</p> <p><strong><code>items</code></strong> — the navigation links. Each item has three fields:</p> <div class="table-responsive"><table> <thead><tr> <th>Field</th> <th>Purpose</th> <p></tr></thead></p> <tbody> <tr> <td><code>title</code></td> <td>The text shown in the desktop navigation bar</td> <p></tr></p> <tr> <td><code>mobile_title</code></td> <td>The text shown in the mobile drawer menu (may be longer)</td> <p></tr></p> <tr> <td><code>url</code></td> <td>The destination. Use <code>/</code> for the homepage, <code>/page/</code> for other pages.</td> <p></tr></p> <p></tbody></table></div></p> <p>Add, remove, or reorder items freely. The order in the YAML is the order in the navigation bar.</p> <p><strong><code>secondary</code></strong> — the secondary CTA button (a ghost button with border). Typically used for pricing or a less-prominent action. It appears to the left of the primary CTA.</p> <p><strong><code>cta</code></strong> — the primary CTA button (filled with brand color). Typically "Get Started" or "Deploy" or "Contact." This is the most prominent call to action on the site.</p> <p><strong>Important rules:</strong></p> <li><strong>URLs should end with a trailing slash</strong> for pages: <code>/about/</code>, <code>/contact/</code>. Home is <code>/</code> (no extra slash). Anchor links on the homepage use <code>/#section</code>: <code>/#pricing</code>, <code>/#contact</code>.</li> <li><strong>The <code>mobile_title</code> field is optional.</strong> If omitted, the <code>title</code> is used in the mobile drawer. It exists so you can have short desktop labels and longer mobile labels, which is often better UX.</li> <li><strong>Navigation is not sorted automatically.</strong> The order you write is the order rendered.</li> <h3><code>_data/footer.yaml</code> — Footer Structure</h3> <p>This file defines the entire footer: the brand column, three link columns, the copyright line, and the legal link bar at the bottom.</p> <p>A complete <code>footer.yaml</code> looks like this:</p> <pre><code>brand: <p> symbol: ".NET"</p> <p> name: "DAX"</p> <p> accent: "PRO"</p> <p>brand_desc: "The ultra-luxurious corporate theme designed for high-velocity Microsoft .NET Static Site Generators and Decap CMS. Powered by pure semantic HTML5, CSS3, and modern engineering principles."</p> <p>compatibility:</p> <p> - "Microsoft .NET 8 / 9"</p> <p> - "·"</p> <p> - "Decap CMS 3.x"</p> <p> - "·"</p> <p> - "Pure HTML5"</p> <p>column1:</p> <p> title: "Architecture"</p> <p> list:</p> <p> - name: "Static Compilation"</p> <p> link: "/services/"</p> <p> - name: "Decap CMS Bridge"</p> <p> link: "/services/"</p> <p> - name: "Azure CI/CD Pipeline"</p> <p> link: "/services/"</p> <p> - name: "Security Audits"</p> <p> link: "/about/"</p> <p> - name: "Benchmark Telemetry"</p> <p> link: "/tags/"</p> <p>column2:</p> <p> title: "Resources"</p> <p> list:</p> <p> - name: "Technical Insights"</p> <p> link: "/posts/"</p> <p> - name: "Decap CMS Guide"</p> <p> link: "/posts/"</p> <p> - name: "Architecture Directory"</p> <p> link: "/tags/"</p> <p> - name: ".NET Articles"</p> <p> link: "/tags/"</p> <p> - name: "Dax Core Project"</p> <p> link: "https://dax.axcora.com"</p> <p>column3:</p> <p> title: "Company"</p> <p> list:</p> <p> - name: "About Dax Pro"</p> <p> link: "/about/"</p> <p> - name: "Enterprise Services"</p> <p> link: "/services/"</p> <p> - name: "Commercial Licensing"</p> <p> link: "/license/"</p> <p> - name: "Contact Engineering"</p> <p> link: "/contact/"</p> <p> - name: "SLA & Support"</p> <p> link: "/contact/"</p> <p>copyright: "© 2026 Dax Pro. Developed for the Microsoft .NET SSG ecosystem and Decap CMS community. All rights reserved."</p> <p>legal:</p> <p> - title: "Privacy Policy"</p> <p> url: "/privacy/"</p> <p> - title: "Terms of Service"</p> <p> url: "/terms/"</p> <p> - title: "License"</p> <p> url: "/license/"</p> <p></code></pre></p> <p><strong>What each section does:</strong></p> <p><strong><code>brand</code></strong> — the footer wordmark. Same structure as <code>nav.yaml</code>. It is defined separately here so the footer brand can differ from the navigation brand if desired. In practice, both usually show the same wordmark.</p> <p><strong><code>brand_desc</code></strong> — a short paragraph under the footer wordmark. Two to four sentences is typical. Keep it under 200 characters.</p> <p><strong><code>compatibility</code></strong> — a row of small tech badges. In the default theme, these appear as text separated by middle dots: <code>Microsoft .NET 8 / 9 · Decap CMS 3.x · Pure HTML5</code>. The middle dots (<code>·</code>) are literal list items. Replace or remove as needed.</p> <p><strong><code>column1</code>, <code>column2</code>, <code>column3</code></strong> — three link columns. Each has a <code>title</code> (column header) and a <code>list</code> (the links). Each link has a <code>name</code> (display text) and a <code>link</code> (URL).</p> <p><strong><code>copyright</code></strong> — the copyright line, shown at the bottom of the footer.</p> <p><strong><code>legal</code></strong> — the legal link bar. A horizontal list of small links in the very bottom of the footer. Typically privacy, terms, and license.</p> <p><strong>Important rules:</strong></p> <li><strong>Column titles are freeform.</strong> "Architecture," "Resources," "Company" are examples. Change them to anything that fits your site.</li> <li><strong>Every column is required.</strong> The theme renders three columns. If you only have two, repeat a column or set one to a single link.</li> <li><strong>Legal link titles and URLs are independent.</strong> The title is display text; the URL is the destination. <code>"Privacy Policy"</code> → <code>"/privacy/"</code> is correct.</li> <li><strong>External links are fine.</strong> <code>"https://dax.axcora.com"</code> in <code>link</code> opens in a new tab if the template marks it as external. In Dax Pro, all footer links open in place — the destination is determined by the URL itself, not a flag.</li> <h3>What Is Not in <code>_data/</code></h3> <p>The <code>_data/</code> folder holds site-wide configuration. It does <strong>not</strong> hold:</p> <li>Page-specific content (that lives in <code>content/</code>)</li> <li>Images (those live in <code>public/images/</code>)</li> <li>Templates (those live in <code>templates/</code>)</li> <li>Deployment configuration (that lives in <code>netlify.toml</code> and <code>vercel.json</code>)</li> <p>If you are looking for the text of a specific blog post or the layout of a specific page, it is not in <code>_data/</code>.</p> <hr/> <h2>Folder 2 — <code>content/</code></h2> <p>The <code>content/</code> folder holds every piece of content on the site. Every page, every post, every service, every tag — all of it originates as a Markdown file in <code>content/</code>.</p> <p>The structure of <code>content/</code> determines the URL of every page. Dax Pro uses a simple rule: <strong>the file's path within <code>content/</code> becomes its URL path</strong>.</p> <pre><code>content/about.md → /about/ <p>content/contact.md → /contact/</p> <p>content/posts/hello-world.md → /posts/hello-world/</p> <p>content/services/design.md → /services/design/</p> <p></code></pre></p> <p>A file named <code>index.md</code> inside a folder becomes the folder's index. So:</p> <pre><code>content/posts/index.md → /posts/ <p>content/docs/index.md → /docs/</p> <p></code></pre></p> <p>Dax Pro ships with the following content structure:</p> <pre><code>content/ <p>├── index.md ← homepage</p> <p>├── about.md ← /about/</p> <p>├── contact.md ← /contact/</p> <p>├── privacy.md ← /privacy/</p> <p>├── terms.md ← /terms/</p> <p>├── license.md ← /license/</p> <p>├── posts.md ← controller for /posts/</p> <p>├── posts/ ← blog posts</p> <p>│ ├── first-post.md</p> <p>│ ├── second-post.md</p> <p>│ └── ...</p> <p>├── services.md ← controller for /services/</p> <p>├── services/ ← service detail pages</p> <p>│ ├── service-one.md</p> <p>│ └── ...</p> <p>└── tags.md ← controller for /tags/</p> <p></code></pre></p> <p>Each type of file has a specific purpose. The rest of this chapter explains them.</p> <h3>Content Files Are Markdown With Frontmatter</h3> <p>Every file in <code>content/</code> is a Markdown file with a <strong>frontmatter block</strong> at the top. Frontmatter is YAML between two sets of triple dashes. The content after the frontmatter is the Markdown body.</p> <pre><code>--- <p>layout: "post.dax"</p> <p>title: "My First Post"</p> <p>description: "A short description"</p> <p>date: 2026-05-04</p> <hr/> <h1>Body content starts here</h1> <p>This is the Markdown body. It is rendered into HTML by the engine.</p> <p></code></pre></p> <p>The frontmatter is required. If it is missing or malformed, the entire file will render as plain text instead of as a page. Two rules are absolute:</p> <p><strong>Rule 1: The file must start with <code>---</code> on its own line.</strong> No spaces before, no BOM character, no other text. Just <code>---</code>.</p> <p><strong>Rule 2: The frontmatter must end with <code>---</code> on its own line, followed by a blank line.</strong> The blank line after the closing <code>---</code> is not optional. If you omit it, the closing <code>---</code> is treated as part of the body, and the frontmatter is not parsed.</p> <p>Both rules exist because of how Markdown parsers work. They are not Dax Pro quirks — they are the standard Markdown frontmatter format used by Jekyll, Hugo, Eleventy, and every other static site generator.</p> <h3><code>content/index.md</code> — The Homepage</h3> <p>The homepage lives at <code>content/index.md</code>. This is the only file that produces the site root (<code>/</code>). Its structure is different from other pages because the homepage is composed of many sections: hero, trust, solutions, performance, showcase, pricing, insights, contact.</p> <p>The frontmatter of <code>index.md</code> is the longest in the project. It contains nested data for every section:</p> <pre><code>--- <p>layout: home.dax</p> <p>title: "Dax Pro — Enterprise .NET Static Site Generator & Decap CMS"</p> <p>description: "Ultra-luxurious, corporate pure HTML/CSS/JS theme..."</p> <p>image: "https://images.unsplash.com/..."</p> <p>hero:</p> <p> kicker: "Enterprise .NET Static Site Generator"</p> <p> title_prefix: "High-Velocity Static Architecture for"</p> <p> title_highlight: "Microsoft .NET"</p> <p> title_suffix: "& Decap CMS"</p> <p> lead: "Dax Pro transforms..."</p> <p> cta_primary:</p> <p> text: "Request Enterprise Evaluation"</p> <p> url: "#contact"</p> <p> # ... and so on</p> <hr/> <p></code></pre></p> <p>The body of <code>index.md</code> is usually empty (or contains only a Markdown heading) because all content is expressed in the frontmatter, and each section is rendered by its own partial template.</p> <p><strong>Editing the homepage</strong> means editing the frontmatter in <code>index.md</code>. There are no partial templates to touch. Change <code>hero.title_prefix</code> to change the headline. Change <code>pricing.tier2.price</code> to change the price. Change <code>contact.email</code> to change the email address.</p> <h3><code>content/about.md</code>, <code>contact.md</code>, <code>privacy.md</code>, <code>terms.md</code>, <code>license.md</code> — Static Pages</h3> <p>These are <strong>static pages</strong>: single pages that are not part of a collection. Each one produces a single URL:</p> <li><code>about.md</code> → <code>/about/</code></li> <li><code>contact.md</code> → <code>/contact/</code></li> <li><code>privacy.md</code> → <code>/privacy/</code></li> <li><code>terms.md</code> → <code>/terms/</code></li> <li><code>license.md</code> → <code>/license/</code></li> <p>Each has the same structure:</p> <pre><code>--- <p>layout: "page.dax"</p> <p>title: "About Dax Pro"</p> <p>breadcrumb: "About"</p> <p>description: "A short description for SEO"</p> <p>cta:</p> <p> title: "Ready to get started?"</p> <p> description: "..."</p> <p> button1_text: "Buy Now"</p> <p> button1_url: "/#pricing"</p> <p> button1_class: "dax-btn-primary"</p> <p> button2_text: "Contact"</p> <p> button2_url: "/contact/"</p> <p> button2_class: "dax-btn-secondary"</p> <hr/> <h2>Markdown body</h2> <p>This is where the page content lives. Write normally with Markdown.</p> <p></code></pre></p> <p>The frontmatter has five fields:</p> <div class="table-responsive"><table> <thead><tr> <th>Field</th> <th>Purpose</th> <p></tr></thead></p> <tbody> <tr> <td><code>layout</code></td> <td>Which template renders this page. For static pages, always <code>page.dax</code>.</td> <p></tr></p> <tr> <td><code>title</code></td> <td>The page's title. Used in <code><title></code>, the H1, and the breadcrumb.</td> <p></tr></p> <tr> <td><code>breadcrumb</code></td> <td>Optional short label for the breadcrumb bar. If omitted, <code>title</code> is used.</td> <p></tr></p> <tr> <td><code>description</code></td> <td>Meta description for SEO. Aim for 150–160 characters.</td> <p></tr></p> <tr> <td><code>cta</code></td> <td>Optional call-to-action box at the bottom of the page. Omit for legal pages.</td> <p></tr></p> <p></tbody></table></div></p> <p>The body of the file is the page's content in Markdown. Standard Markdown applies: headings, paragraphs, bold, italic, lists, links, images, code blocks, blockquotes.</p> <p>The <code>cta</code> section is optional. Legal pages like <code>privacy.md</code> and <code>terms.md</code> usually omit it. Marketing pages like <code>about.md</code> include it to drive conversion.</p> <h3><code>content/posts/</code> — Blog Collection</h3> <p>The <code>posts/</code> folder holds blog articles. Every <code>.md</code> file inside <code>posts/</code> becomes a blog post at <code>/posts/{filename}/</code>.</p> <pre><code>content/posts/why-static-sites.md → /posts/why-static-sites/ <p>content/posts/blazor-vs-dax.md → /posts/blazor-vs-dax/</p> <p>content/posts/decap-cms-guide.md → /posts/decap-cms-guide/</p> <p></code></pre></p> <p>Each post has a standard frontmatter:</p> <pre><code>--- <p>layout: "post.dax"</p> <p>title: "Why Static Sites Beat Dynamic CMS"</p> <p>description: "A detailed look at why static site generators win for content"</p> <p>image: "https://images.unsplash.com/..."</p> <p>date: 2026-05-04</p> <p>category: "Architecture"</p> <p>read_time: "6 min read"</p> <p>read_more: "Read Analysis"</p> <p>author: "Axcora"</p> <p>tags: ["dotnet", "static", "performance"]</p> <p>excerpt: "A short summary shown in the blog listing card"</p> <hr/> <p>Markdown body of the post goes here.</p> <p></code></pre></p> <p>Fields explained:</p> <div class="table-responsive"><table> <thead><tr> <th>Field</th> <th>Purpose</th> <p></tr></thead></p> <tbody> <tr> <td><code>layout</code></td> <td>Always <code>post.dax</code> for blog posts.</td> <p></tr></p> <tr> <td><code>title</code></td> <td>Post title. Used in <code><title></code>, H1, listing card, prev/next nav.</td> <p></tr></p> <tr> <td><code>description</code></td> <td>Meta description for SEO.</td> <p></tr></p> <tr> <td><code>image</code></td> <td>Featured image. Used as OpenGraph image and as the listing card thumbnail.</td> <p></tr></p> <tr> <td><code>date</code></td> <td>Publication date in <code>YYYY-MM-DD</code> format. Used for sorting.</td> <p></tr></p> <tr> <td><code>category</code></td> <td>A single category name for the post. Shown in the meta line.</td> <p></tr></p> <tr> <td><code>read_time</code></td> <td>Human-readable read estimate. You determine this; the engine does not calculate it.</td> <p></tr></p> <tr> <td><code>read_more</code></td> <td>Label for the "read more" link on the listing card. Defaults to "Read Article" if omitted.</td> <p></tr></p> <tr> <td><code>author</code></td> <td>Author name. Shown in the meta line.</td> <p></tr></p> <tr> <td><code>tags</code></td> <td>List of tags. <strong>Must be lowercase</strong> — tags are used as URL slugs.</td> <p></tr></p> <tr> <td><code>excerpt</code></td> <td>Short summary shown on the listing page.</td> <p></tr></p> <p></tbody></table></div></p> <p><strong>Important: tags must be lowercase.</strong> A tag <code>"DotNet"</code> produces a URL <code>/tags/DotNet/</code>, but the actual tag page is generated at <code>/tags/dotnet/</code>. Uppercase tags break the tag links. Always write tags in lowercase: <code>"dotnet"</code>, <code>"razor"</code>, <code>"blazor"</code>, <code>"decapcms"</code>.</p> <p><strong>Post ordering:</strong> posts are sorted by <code>date</code> in descending order. The most recent post appears first on <code>/posts/</code> and in the homepage's Insights section. If two posts share a date, they are ordered alphabetically by URL.</p> <p><strong>Adding a new post:</strong> create a new <code>.md</code> file in <code>content/posts/</code>, fill in the frontmatter, write the body, and rebuild. The post will appear in the listing automatically.</p> <p><strong>Removing a post:</strong> delete the <code>.md</code> file from <code>content/posts/</code> and rebuild. The post will no longer appear.</p> <h3><code>content/services/</code> — Service Collection</h3> <p>The <code>services/</code> folder holds service detail pages. It works exactly like <code>posts/</code>, but for services rather than articles.</p> <pre><code>content/services/dotnet-architecture.md → /services/dotnet-architecture/ <p>content/services/cms-migration.md → /services/cms-migration/</p> <p></code></pre></p> <p>A service has this frontmatter:</p> <pre><code>--- <p>layout: "service.dax"</p> <p>title: ".NET Static Site Generator Architecture"</p> <p>description: "Custom .NET SSG architecture for enterprise teams"</p> <p>image: "https://images.unsplash.com/..."</p> <p>index: "01. COMPILATION"</p> <p>read_more: "Explore Solution Architecture"</p> <p>date: 2026-05-04</p> <p>tags: ["dotnet", "razor", "blazor"]</p> <p>cta:</p> <p> title: "Need a custom .NET SSG architecture?"</p> <p> description: "Hire a dedicated .NET engineer for bespoke setup."</p> <p> button1_text: "Hire on Fiverr"</p> <p> button1_url: "https://www.fiverr.com/..."</p> <p> button1_class: "dax-btn-primary"</p> <p> button2_text: "Order Dax Pro Theme"</p> <p> button2_url: "https://creativitaz.gumroad.com/l/dax-pro"</p> <p> button2_class: "dax-btn-secondary"</p> <hr/> <p>Markdown body of the service page.</p> <p></code></pre></p> <p>Fields explained:</p> <div class="table-responsive"><table> <thead><tr> <th>Field</th> <th>Purpose</th> <p></tr></thead></p> <tbody> <tr> <td><code>layout</code></td> <td>Always <code>service.dax</code> for service pages.</td> <p></tr></p> <tr> <td><code>title</code></td> <td>Service title.</td> <p></tr></p> <tr> <td><code>description</code></td> <td>Meta description and card summary.</td> <p></tr></p> <tr> <td><code>image</code></td> <td>Optional feature image.</td> <p></tr></p> <tr> <td><code>index</code></td> <td>A short badge like <code>"01. COMPILATION"</code>. Shown above the title.</td> <p></tr></p> <tr> <td><code>read_more</code></td> <td>Label for the listing card's "read more" link.</td> <p></tr></p> <tr> <td><code>date</code></td> <td>Sort order for the services listing.</td> <p></tr></p> <tr> <td><code>tags</code></td> <td>List of lowercase tags.</td> <p></tr></p> <tr> <td><code>cta</code></td> <td>Call-to-action box at the bottom of the service page. Two buttons supported.</td> <p></tr></p> <p></tbody></table></div></p> <p>The <code>cta</code> block is a nested object with two buttons. Every service should include it, because the service detail page's primary conversion point is the CTA at the bottom.</p> <p><strong>Service ordering</strong> is determined by <code>date</code>, like posts. The service with the most recent <code>date</code> appears first in <code>/services/</code>.</p> <h3>Controller Files — <code>posts.md</code>, <code>services.md</code>, <code>tags.md</code></h3> <p>Three files in <code>content/</code> look like regular Markdown but are not. They are <strong>controllers</strong> — files that tell Dax Pro to generate a paginated listing for a collection.</p> <p><strong><code>content/posts.md</code>:</strong></p> <pre><code>--- <p>layout: "posts-list.dax"</p> <p>title: "Engineering Publications & Blueprints"</p> <p>breadcrumb: "Technical Insights"</p> <p>description: "Architectural analyses, performance benchmarks, and headless content modeling strategies."</p> <p>collection: "posts"</p> <p>pagination: 6</p> <hr/> <p></code></pre></p> <p><strong><code>content/services.md</code>:</strong></p> <pre><code>--- <p>layout: "services-list.dax"</p> <p>title: "Specialized .NET SSG Architecture Services"</p> <p>breadcrumb: "Enterprise Services"</p> <p>description: "End-to-end consulting, migration roadmaps, and custom theme engineering."</p> <p>collection: "services"</p> <p>pagination: 6</p> <hr/> <p></code></pre></p> <p><strong><code>content/tags.md</code>:</strong></p> <pre><code>--- <p>layout: "tags.dax"</p> <p>title: "Architecture & Subject Index"</p> <p>breadcrumb: "Taxonomy Directory"</p> <p>description: "Browse specialized technical subjects across the Dax Pro ecosystem."</p> <hr/> <p></code></pre></p> <p><strong>How controllers work:</strong></p> <p>The <code>collection</code> field names the folder whose items should be listed. <code>collection: "posts"</code> means "list the items in <code>content/posts/</code>". The <code>pagination</code> field says how many items to show per page.</p> <p>With <code>pagination: 6</code> and 13 posts, Dax Pro generates:</p> <li><code>/posts/</code> with posts 1–6</li> <li><code>/posts/page/2/</code> with posts 7–12</li> <li><code>/posts/page/3/</code> with post 13</li> <p>The <code>tags.md</code> file works differently: it does not have a <code>collection</code> field. It is the index for all tags, generated automatically from the <code>tags</code> fields across all content.</p> <p><strong>Do not delete controller files.</strong> If <code>posts.md</code> is missing, the <code>/posts/</code> listing will not be generated, and every blog post will be reachable only by direct URL. The controller is what creates the listing page.</p> <p><strong>Do not add a <code>collection</code> field to non-controller files.</strong> If you add <code>collection: "posts"</code> to <code>content/about.md</code>, Dax Pro will think <code>about.md</code> is a second posts controller and generate a duplicate listing.</p> <h3>Content File Naming Rules</h3> <p>File names become URL slugs. Keep them lowercase, use hyphens for spaces, and avoid special characters.</p> <p><strong>Good file names:</strong></p> <pre><code>why-static-sites-win.md <p>decap-cms-enterprise-guide.md</p> <p>dotnet-architecture.md</p> <p></code></pre></p> <p><strong>Bad file names:</strong></p> <pre><code>Why Static Sites Win.md ← spaces break URLs <p>Decap_CMS_Guide.md ← underscores are valid but ugly</p> <p>dotnet architecture.md ← space breaks URL</p> <p></code></pre></p> <p>The URL produced is the filename minus <code>.md</code>, lowercased, with spaces converted to hyphens. Following the good naming convention above means the URL is exactly what you expect.</p> <hr/> <h2>How the Two Folders Connect</h2> <p>To understand how <code>_data/</code> and <code>content/</code> work together, consider what happens when someone visits <code>https://yoursite.com/about/</code>:</p> <p>1. Dax Pro looks for <code>content/about.md</code></p> <p>2. It reads the frontmatter — <code>title</code>, <code>description</code>, <code>layout: page.dax</code>, optional <code>cta</code></p> <p>3. It also reads <code>_data/metadata.yaml</code> for the site title, meta description fallback, URL, and image</p> <p>4. It reads <code>_data/nav.yaml</code> for the navigation bar</p> <p>5. It reads <code>_data/footer.yaml</code> for the footer</p> <p>6. It applies the <code>page.dax</code> layout, injecting the frontmatter values and the <code>_data/</code> values</p> <p>7. It writes the final HTML to <code>site/about/index.html</code></p> <p>The result: a page whose content is unique (from <code>content/about.md</code>) but whose navigation, footer, and SEO defaults come from <code>_data/</code>. Change <code>_data/nav.yaml</code>, and <strong>every page</strong> updates. Change <code>content/about.md</code>, and <strong>only <code>/about/</code></strong> updates.</p> <p>This separation is why <code>_data/</code> exists. If navigation were defined in every Markdown file, you would have to change it in a hundred places. Because it lives in one YAML file, you change it once.</p> <hr/> <h2>What You Should Edit, and What You Should Not</h2> <p>Now that you know the two folders, here is a quick decision table for day-to-day edits.</p> <div class="table-responsive"><table> <thead><tr> <th>If you want to change...</th> <th>Edit this file</th> <p></tr></thead></p> <tbody> <tr> <td>The site title shown in <code><title></code></td> <td><code>_data/metadata.yaml</code> → <code>title</code></td> <p></tr></p> <tr> <td>The site description for SEO</td> <td><code>_data/metadata.yaml</code> → <code>description</code></td> <p></tr></p> <tr> <td>The favicon</td> <td><code>_data/metadata.yaml</code> → <code>icon</code> (and place the file in <code>public/images/</code>)</td> <p></tr></p> <tr> <td>The OpenGraph image</td> <td><code>_data/metadata.yaml</code> → <code>image</code></td> <p></tr></p> <tr> <td>Navigation links</td> <td><code>_data/nav.yaml</code> → <code>items</code></td> <p></tr></p> <tr> <td>The brand wordmark in the navbar</td> <td><code>_data/nav.yaml</code> → <code>brand</code></td> <p></tr></p> <tr> <td>The primary CTA button</td> <td><code>_data/nav.yaml</code> → <code>cta</code></td> <p></tr></p> <tr> <td>Footer link columns</td> <td><code>_data/footer.yaml</code> → <code>column1</code>, <code>column2</code>, <code>column3</code></td> <p></tr></p> <tr> <td>The footer copyright line</td> <td><code>_data/footer.yaml</code> → <code>copyright</code></td> <p></tr></p> <tr> <td>The privacy and terms links</td> <td><code>_data/footer.yaml</code> → <code>legal</code></td> <p></tr></p> <tr> <td>The homepage text</td> <td><code>content/index.md</code> (frontmatter)</td> <p></tr></p> <tr> <td>The about page text</td> <td><code>content/about.md</code> (frontmatter + body)</td> <p></tr></p> <tr> <td>A blog post</td> <td><code>content/posts/{slug}.md</code></td> <p></tr></p> <tr> <td>A service detail page</td> <td><code>content/services/{slug}.md</code></td> <p></tr></p> <tr> <td>The blog listing page title</td> <td><code>content/posts.md</code> → <code>title</code></td> <p></tr></p> <tr> <td>The number of posts per page</td> <td><code>content/posts.md</code> → <code>pagination</code></td> <p></tr></p> <p></tbody></table></div></p> <p>If the file is under <code>_data/</code>, your change affects <strong>every page</strong>. If the file is under <code>content/</code>, your change affects <strong>only that page</strong>.</p> <hr/> <h2>Rules That Prevent Most Bugs</h2> <p>These four rules prevent 90% of the bugs users hit on their first day.</p> <p><strong>Rule 1: Files must start with <code>---</code>.</strong> No spaces, no blank lines, no BOM. Just <code>---</code> on line 1.</p> <p><strong>Rule 2: The closing <code>---</code> must be followed by a blank line.</strong> The blank line separates frontmatter from body. Without it, the body is not parsed as Markdown.</p> <p><strong>Rule 3: Quote all YAML values that contain colons, hashes, or start with symbols.</strong> <code>title: "My: Title"</code> is correct. <code>title: My: Title</code> is a parse error.</p> <p><strong>Rule 4: Use LF line endings, not CRLF.</strong> Windows editors default to CRLF, which the DAX YAML parser does not accept. Configure your editor to save with LF (see the Installation chapter). If you forget, the frontmatter will render as plain text on the page — a confusing symptom for a simple cause.</p> <p>If your page shows raw YAML on the rendered site — with <code>---</code> and <code>title:</code> visible in the body — one of these four rules was broken. Fix the file and rebuild.</p> <hr/> <h2>What You Have Now</h2> <p>After reading this chapter, you understand:</p> <li>✅ The project has two content folders: <code>_data/</code> and <code>content/</code></li> <li>✅ <code>_data/</code> holds three YAML files: <code>metadata.yaml</code>, <code>nav.yaml</code>, <code>footer.yaml</code></li> <li>✅ <code>content/</code> holds Markdown files with frontmatter, organized by URL path</li> <li>✅ <code>index.md</code> is the homepage; <code>about.md</code> etc. are static pages</li> <li>✅ <code>posts/</code> and <code>services/</code> are collections with their own controller files</li> <li>✅ File names become URL slugs</li> <li>✅ Tags must be lowercase</li> <li>✅ Four rules prevent the most common bugs</li> <p></ul>The next chapter, <strong>Configuration</strong>, walks through editing <code>_data/metadata.yaml</code>, <code>_data/nav.yaml</code>, and <code>_data/footer.yaml</code> step by step. That is the first practical task after installation — getting the site identity correct before writing content.</p> <p>→ Continue to <a href="/docs/configuration/">Configuration</a></p> </div> </div> </article> </main> <script> (function() { const docsToggle = document.getElementById('dax-docs-toggle'); const docsSidebar = document.querySelector('.dax-docs-sidebar'); const docsOverlay = document.getElementById('dax-docs-overlay'); if (!docsToggle || !docsSidebar) return; const closeDocs = () => { docsToggle.setAttribute('aria-expanded', 'false'); docsSidebar.classList.remove('open'); if (docsOverlay) docsOverlay.classList.remove('open'); document.body.classList.remove('dax-docs-open'); }; docsToggle.addEventListener('click', () => { const isOpen = docsSidebar.classList.contains('open'); if (isOpen) { closeDocs(); } else { docsToggle.setAttribute('aria-expanded', 'true'); docsSidebar.classList.add('open'); if (docsOverlay) docsOverlay.classList.add('open'); document.body.classList.add('dax-docs-open'); } }); if (docsOverlay) docsOverlay.addEventListener('click', closeDocs); document.addEventListener('keydown', (e) => { if (e.key === 'Escape') closeDocs(); }); document.querySelectorAll('.dax-docs-nav-link').forEach(link => { link.addEventListener('click', closeDocs); }); })(); </script> <footer class="dax-footer"> <div class="dax-container"> <div class="dax-footer-top"> <div class="dax-footer-brand-col"> <a href="/" class="dax-brand"> <span class="dax-brand-symbol">.NET</span> <span class="dax-brand-name" style="color: #FFFFFF;">DAX<span class="dax-brand-accent">PRO</span></span> </a> <p class="dax-footer-desc">The ultra-luxurious corporate theme designed for high-velocity Microsoft .NET Static Site Generators and Decap CMS. Powered by pure semantic HTML5, CSS3, and modern engineering principles.</p> <div class="dax-footer-compatibility"> <span>Microsoft .NET 8 / 9</span> <span>·</span> <span>Decap CMS 3.x</span> <span>·</span> <span>Pure HTML5</span> </div> </div> <div> <h4 class="dax-footer-col-title">Architecture</h4> <ul class="dax-footer-links"> <li><a href="/services/dotnet-ssg-architecture/" class="dax-footer-link">Static Compilation</a></li> <li><a href="/services/decap-cms-workflow/" class="dax-footer-link">Decap CMS Bridge</a></li> <li><a href="/services/azure-devops-github-actions/" class="dax-footer-link">Azure CI/CD Pipeline</a></li> <li><a href="/services/performance-wcag-audits/" class="dax-footer-link">Security Audits</a></li> <li><a href="/services/legacy-cms-migration/" class="dax-footer-link">Benchmark Telemetry</a></li> </ul> </div> <div> <h4 class="dax-footer-col-title">Resources</h4> <ul class="dax-footer-links"> <li><a href="/docs/" class="dax-footer-link">Documentation</a></li> <li><a href="/posts/" class="dax-footer-link">Technical Insights</a></li> <li><a href="/tags/" class="dax-footer-link">Architecture Directory</a></li> <li><a href="https://dax.axcora.com" class="dax-footer-link">Dax Core Project</a></li> </ul> </div> <div> <h4 class="dax-footer-col-title">Company</h4> <ul class="dax-footer-links"> <li><a href="/about/" class="dax-footer-link">About Dax Pro</a></li> <li><a href="/services/" class="dax-footer-link">Enterprise Services</a></li> <li><a href="/license/" class="dax-footer-link">Commercial License</a></li> <li><a href="/contact/" class="dax-footer-link">Contact Engineering</a></li> </ul> </div> </div> <div class="dax-footer-bottom"> <div>© 2026 Dax Pro. Developed for the Microsoft .NET SSG ecosystem and Decap CMS community. All rights reserved.</div> <div class="dax-footer-bottom-links"> <a href="/privacy/" class="dax-footer-link">Privacy Policy</a> <a href="/terms/" class="dax-footer-link">Terms of Service</a> <a href="/license/" class="dax-footer-link">License</a> </div> </div> </div> </footer> <script src="/js/main.js" defer></script> </body> </html>