Hugo, without the terminal.

Every Hugo site you have, in one sidebar. Add them one at a time with ⌘O, clone one straight from a Git URL, or point HugoKit at the folder you keep your projects in and let it find them itself.

• Watch a folder: HugoKit scans up to three levels deep, adds every folder that holds a Hugo config, and skips the ones that never contain a site of their own – public, resources, themes, archetypes, .git, node_modules, .build and vendor.
• A folder counts as a site when it has a Hugo config file. If the config is there but the folders around it look incomplete, the site is added with a warning rather than turned away.
• Add a site straight from a Git URL – paste the repository, choose where to clone it, and HugoKit clones and adds it in one step. A token is only ever sent to github.com.
• Pin the ones you use most, and give each site an emoji so the sidebar is scannable at a glance.
• Each site keeps its own settings – its port, its content toggles, its deploy destinations.

Preflight blocks what breaks a deployed site. Site Health – ⇧⌘H from anywhere – reports on the site itself: broken links, images without alt text, config keys Hugo has deprecated. Findings are listed for you to act on; Site Health does not edit the site.

• Nine checks run in parallel: broken internal links, images without alt text, images over 500 KB, deprecated config keys, a missing favicon, build-time regressions, front matter gaps, draft ratio and a stale search index.
• A score out of 100 – an error costs 10 points, a warning 5, an info 2 – and every issue is tagged CONTENT, PERF, A11Y or CONFIG.
• Front matter issues are aggregated per field, so 200 posts without a date cost you one issue, not two hundred.
• It reads the built site in public/, so build before you read too much into the score.

A layout file is invisible until a page renders it. Template Preview (⇧⌘T) puts your layouts on the left and the rendered page on the right, served by your own dev server – so you can see what single.html actually does without hunting for a URL that exercises it.

• Your layouts/ and every theme’s layouts/ in one tree – and where both define the same file, the project’s version wins, exactly as Hugo resolves it.
• Preview with picks a real page from your content that the selected template actually renders; partials, shortcodes and baseof fall back to the home page.
• The preview is live: save the file in your editor and it reloads like any other page.
• It needs the dev server running – if it is stopped, the panel says so and offers to start it.

The Content page counts what is in the site and lists the files. It is built for a typo, a front matter field, a date – not for writing. A front matter inspector sits beside each file for exactly those fields; real writing stays in your own editor, and the preview reloads on save either way.

• Pages, sections, word counts and images per site – plus how many are drafts, future-dated or expired. A page bundle shows as one entry with its images, not a folder of loose files.
• Search the list by title, section or path with ⌘F. Matching ignores case and diacritics, so aben finds Åben.
• With a Raw editor active, ⌘F opens a native find bar inside the sheet and ⌥⌘F adds replace controls. Replace All is one undo step, and changes stay in the buffer until Save.
• A Changed filter lists what git reports as new, modified, renamed or deleted since the last commit, with the word for which on each row. Sites without git do not show it.
• Edit the front matter in a panel beside the file – title, description, date, tags and categories, with suggestions drawn from the site’s own taxonomies – or use the Raw tab, a plain monospaced editor with an explicit Save (⌘S). Both edit the same text.
• Below the front matter: the files in the page’s bundle, with Quick Look and insert-a-reference, and the pages that link to this one with the line each link sits on.
• In the Raw tab, an outline of the document’s headings. Click one and the cursor moves to that line.
• New Content offers the site’s own archetypes. A directory archetype creates a leaf bundle with the archetype’s files inside it.
• See every tag and category across the site, catch a duplicate spelling, and rename one everywhere in a single pass you can undo.
• On a site with configured languages, a page’s translations can be grouped onto one row. Read-only, and filenames are left as the site writes them.
• Close a file with unsaved changes and HugoKit asks first.
• Open in editor is one click away, in whatever editor you already use.

Your config is the file most likely to break a site, and the one you edit least often – so you never quite remember what the keys are called. HugoKit gives it a form, a raw text tab, and one rule: nothing is written to disk until you have seen the diff.

• The form is grouped: Basics, Build, Author, Params, Markup, Taxonomies, Main Menu and Additional Fields.
• The two tabs are the same document – type a key in Raw and it turns up in the form, and the other way round.
• Save does not save. It shows every changed key, old value against new; you approve, and then it is written.
• TOML, YAML or JSON – the format is read from the file, and keys you never touched keep their place, their spelling and their comments.

Nothing changes without a diff, and everything can be undone. Whenever HugoKit writes to your site – a preflight fix, a config save, a content edit, a theme switch – it snapshots the affected files first.

• Snapshots live in the app’s own storage, never in your repository – so they can’t be committed or published by accident.
• Every write is recorded as a per-file diff. Read it in place, copy it out, or undo just that file.
• Restore brings back a whole operation – and takes its own snapshot first, so even an undo can be undone.
• Per site, you decide: turn the layer off, or set how many versions of each file to keep.