Hugo is fast, flexible, and opinionated in all the right ways — but it ships without built-in search. Since Hugo generates a static site, there is no server-side query engine to call. Search has to be handled either at build time, client-side in the browser, or through a third-party service. Each approach has tradeoffs worth understanding before you commit to one. This guide covers the main options and walks through the implementation that works best for most publishing workflows.

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 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.

Hugo is fast to build and fast to get started with, but a blank new site has some deliberate setup work before it is ready to publish. This walkthrough covers the full process from installation through your first deployed post. Installing Hugo Hugo distributes as a single binary — no runtime dependencies, no package manager required after the initial install. macOS: brew install hugo Linux (Debian/Ubuntu): sudo apt install hugo Or download the latest binary directly from the Hugo releases page and add it to your PATH.

Every few years, a platform that indie publishers relied on changes the rules. Algorithm changes cut organic reach. Monetization programs introduce new requirements or reduce payouts. Accounts get suspended without clear appeal paths. The terms shift in ways that favor the platform over the publisher. This is not a new dynamic. It predates the internet. But the specific form it takes now — where a significant portion of an independent publisher’s audience, revenue, and distribution lives on infrastructure controlled by companies whose interests regularly diverge from the publishers they host — is worth examining directly.

For publishers setting up a new site — or reconsidering an old one — the choice between WordPress and Hugo comes up constantly. Both are capable, widely used, and well-supported, but they represent fundamentally different philosophies about how a website should work. Picking the wrong one creates friction you will feel every day. The Core Difference WordPress is a dynamic content management system. Every time a visitor loads a page, WordPress queries a database, assembles the page from PHP templates and stored content, and serves the result.