Hugo archetypes are content templates that pre-populate frontmatter when you create new content with hugo new. They are a small feature with a disproportionate practical impact on a publication’s day-to-day workflow: every new post or page starts with the correct structure, required fields are present, and authors do not need to remember the exact frontmatter format. The Default Archetype Hugo ships with a single default archetype at archetypes/default.md: --- title: "{{ replace .

Hugo has a built-in image processing pipeline that handles resizing, format conversion, and optimization at build time — no external service, no plugin, no JavaScript-based lazy loading required. For publishing sites where images are a significant part of content, understanding Hugo’s image processing is worth the investment. The result is faster pages with properly sized images served in modern formats, generated automatically from source files. Page Resources vs Global Resources Hugo works with images in two contexts:

Hugo partials are reusable template fragments — the building blocks of a maintainable Hugo theme. Any piece of HTML that appears in more than one place belongs in a partial: site headers, footers, navigation menus, article cards, SEO meta tags, social sharing blocks, author bios. Once defined, a partial is called with a single line from any template. This guide covers the full range of how partials work and patterns that make them practical for a publishing site.

Hugo Pipes is Hugo’s built-in asset processing pipeline. It handles Sass/SCSS compilation, CSS and JavaScript minification, fingerprinting for cache busting, and bundling — at build time, without external build tools like Webpack or Vite. For publishers running Hugo sites, understanding Pipes is the difference between manually managing compiled CSS and having the build handle it automatically. The Assets Directory Hugo Pipes works with files in the assets/ directory. Unlike static/, which copies files verbatim to the output, assets/ is a processing source — files there are available to Pipes functions but are only written to the output if explicitly processed and referenced.

Hugo shortcodes are reusable template fragments that can be embedded in Markdown content. They bridge the gap between Markdown’s intentional simplicity and the richer, more structured HTML that publishing sites often need — figure captions, callout boxes, video embeds, custom alert blocks, styled pull quotes — without requiring authors to write raw HTML in their content files. Hugo ships with a small set of built-in shortcodes and provides a straightforward system for building your own.

JAMstack is an architectural approach to building websites that has reshaped how publishers think about performance, security, and hosting. The term has become somewhat elastic with use — vendors apply it broadly — but the underlying principles are specific and worth understanding clearly. What JAMstack Actually Means JAM stands for JavaScript, APIs, and Markup. The original definition describes a web architecture with three characteristics: JavaScript handles all dynamic functionality, running in the browser rather than on the server.

Migrating a WordPress site to Hugo is one of the most common transitions in publishing infrastructure. The reasons vary — performance, hosting cost, maintenance overhead, security exposure — but the path through the migration is broadly the same regardless of why you are making the move. This is a practical walkthrough of what the process actually involves. What You Are Gaining and What You Are Giving Up Before starting, be clear about the tradeoffs.

Email newsletters have become a primary publishing medium — not supplementary to a website but often the core product itself. The platform you build on shapes how you write, how you grow, how you monetize, and critically, how much of your operation you own. Choosing between the leading options requires understanding what each one actually is and who it is built for. Substack Substack is a publishing platform built around the newsletter as a standalone product.

RSS was supposed to have died years ago. Google killed Google Reader in 2013 and the obituaries were written. Podcasting quietly kept RSS alive as its distribution backbone, and a persistent community of readers, developers, and publishers never stopped using it. In 2026, RSS is not only not dead — for certain audiences and publishing contexts, it is more relevant than it has been in a decade. What RSS Actually Is RSS (Really Simple Syndication) is a standardized XML format for publishing frequently updated content.

Sanity is a headless CMS built around a principle it calls “structured content” — the idea that content should be modeled as data first, with presentation a separate concern. For publishers whose content is genuinely complex — articles with rich metadata, multiple content types with relationships, content repurposed across channels — Sanity’s approach delivers a level of flexibility that database-backed traditional CMSes struggle to match. It is not the simplest tool in the category, but for the use cases it is designed for, it is among the most capable.