Hugo turns the Markdown into pages. The browser can read the article without running an application bundle or waiting for a content API. JavaScript adds search, feed controls and theme switching where those interactions are useful.

Keep the dynamic boundary small

Static does not mean every part of the system is static. This portfolio’s CMS authentication uses API functions, while the public writing remains generated HTML. Editing content triggers a new build through GitHub.

That separation suits a personal site because public readers do not need accounts or personalised results. If the product were a collaborative editor or a live operational dashboard, the boundary would need to be different.

Search needs accessible content

Rendering the text into HTML gives crawlers a straightforward document to fetch. It is only the starting point. The site also needs working links, canonical URLs, suitable metadata, a sitemap and useful published content.

This site includes an llms.txt index as another way to find the public pages. It does not guarantee that a search engine or an AI assistant will mention the site. Google’s guidance for AI features still centres on ordinary search eligibility and useful content; it does not require a special AI file.

The technical choice is therefore fairly ordinary: keep the public content easy to load and inspect, then spend the saved complexity on better examples and project evidence.

References: Hugo’s documentation and Google’s guidance on AI features and websites.

The site uses Hugo Extended, a pinned PaperModX theme, custom CSS and a small amount of JavaScript. Vercel serves the generated output. The CMS edits the same Markdown files in GitHub, so a content change goes through the normal deployment path.

Make the environment explicit

The production command is:

1

hugo --gc --minify --environment production

A preview needs a different environment because its search-indexing policy is different:

1

hugo --gc --minify --environment preview --destination public-preview

In this site’s deployment configuration, Vercel’s environment is passed through to Hugo. Production pages can be indexed; preview pages emit noindex. That is a site-template decision, not something the word “preview” magically guarantees in Hugo.

Know what a timing includes

The time Hugo reports for rendering is only one part of a deployment. Downloading the build tool, fetching the theme, preparing assets and uploading output can take longer than generating the HTML.

If a deployment becomes slow, I would measure those stages separately before changing the renderer. A cached build-tool download solves a different problem from an expensive template loop.

Pinning the Hugo version and theme revision also makes a surprising change easier to investigate. Otherwise, a content-only commit can pick up a new dependency and quietly become a software update.

Inspect the output

A successful process exit means the build completed. It does not tell you that a résumé link exists, a draft stayed unpublished or the canonical URL points to the right host.

For this site, those are useful checks on the generated files. They exercise the result someone will actually receive, and they keep the deployment contract small enough to understand when something breaks.

Reference: Hugo command options.