Most of this site’s work happens before anyone opens a page. The content is known at build time: an introduction, project write-ups, technical notes and a résumé link. That makes static HTML a natural fit.
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.