Our company website ran on WordPress with the Divi theme for years. It worked. Pages loaded, the contact form sent emails, the blog had posts. But every time I opened PageSpeed Insights the numbers made me wince. CLS of 0.81. A page weight that had no business being that large for what was mostly text and a few images.
So we tore it down and rebuilt it with Kronk CMS running Hugo underneath.
Why Kronk and Hugo
I wanted a static site. No database, no PHP, no plugin updates, no security patches for a CMS I use as a glorified text editor. Hugo builds the entire site in under two seconds. The result is plain HTML, CSS and a bit of JavaScript. Caddy serves it. There is nothing to hack because there is nothing running.
But Hugo by itself is a build tool, not a content management system. It does not know about SEO constraints, accessibility rules, or how to keep an AI coding agent from breaking your site while editing templates. That is what Kronk adds. kronk init detected the Hugo project, set up guardrail files that Claude Code loads automatically, and gave us quality checks for title lengths, heading structure, alt text, contrast, and a dozen other things that are easy to get wrong across 77 pages.
The migration itself started with kronk migrate wordpress. It pulled the XML export, stripped the Divi shortcodes, converted to Markdown, and mapped the image paths. Some pages needed manual cleanup where Divi had wrapped every paragraph in three nested divs for no reason anyone could explain, but the bulk of the conversion was automated.
The other reason was bilingual support. Our site runs in German and English. WordPress handled this with a translation plugin that added overhead to every page load and broke in creative ways every few months. Hugo has built-in multilingual support. Two content directories, one config file, done.
77 pages, zero missing URLs
The migration covered 77 pages. Every URL from the old site still works - same paths, same slugs, no redirects needed. I spent more time on URL parity than on the actual design. Getting a redirect wrong means a dead link in someone’s bookmark or a search result that goes nowhere. Not worth the risk.
The numbers
Before and after, same pages, same content:
- CLS: 0.81 to 0. The old site had layout shifts from web fonts loading, from images without dimensions, from Divi’s JavaScript rearranging the DOM after page load. Hugo serves the final HTML. Nothing moves.
- Page weight: cut roughly in half. Mostly from removing jQuery, Divi’s framework JavaScript, and converting images to WebP through Hugo’s asset pipeline.
- Time to first byte: dropped from 400-600ms (WordPress hitting MySQL, running PHP, assembling the page) to under 50ms (Caddy serving a static file from disk).
The site looks the same. That was deliberate. We did not redesign the visual identity. We kept the same layout, the same colours, the same structure. The change is under the hood.
What I would do differently
I underestimated the contact form. WordPress has Contact Form 7. Hugo has nothing, because it is a static site generator. I ended up writing a small endpoint that receives the form POST, validates a Cloudflare Turnstile token, and sends the email. It works, but it took longer than expected because I had to handle spam protection from scratch instead of installing a plugin.
I also spent too long on the cookie consent banner. The old site used a WordPress plugin. The new site uses a lightweight consent layer that gates GTM and Chatwoot behind an explicit opt-in. Getting the timing right so that analytics loads only after consent but the page does not flash or shift took several iterations.
The blog you are reading
This blog runs on the same Hugo instance, managed through Kronk. Markdown files in a content directory, a reading-progress bar, related posts at the bottom, social cards generated at build time. Writing a post means creating a .md file and pushing to the production branch. No WordPress editor, no browser, no login. Kronk’s guardrails catch SEO and accessibility issues before the push.
The source is version-controlled. Every change has a commit message. I can diff two versions of a page the same way I diff code. For a company that builds software, having the website in the same workflow as everything else just makes sense.
If you are thinking about moving off WordPress and your site is mostly content - not a web application, not an e-commerce store, just pages and a blog - give Kronk a look. It handles the CMS part so Hugo can do what it does best: build fast.