The short answer
A Hugo or Jekyll site has no admin login because there is no server running a CMS. The site is a folder of text files in a Git repository, and a build step turns them into HTML. To edit it without a developer, you change the right text file and let the build publish it. Most of the words you want to change live in Markdown content files, in the front matter at the top of those files, or in small data files. You can edit those through the GitHub web editor, through a Git-based CMS such as Decap CMS or CloudCannon, or by asking an AI editor in plain language. Layout files are the part to leave to a developer.
Why there is no "edit page" button
WordPress stores pages in a database and renders them on request, so it ships with a dashboard. Static site generators work the other way round. Hugo and Jekyll read your files once, at build time, and output plain HTML. Your host (GitHub Pages, Netlify, Cloudflare Pages, Vercel or similar) usually rebuilds the site every time a change lands in the repository.
That design is why these sites are fast and hard to hack. It is also why a business owner who inherits one from an agency or a freelancer often has no idea where to type. The answer is: in the repository, in the right file.
Where the text actually lives
Before choosing a tool, learn the four places content hides. Every option below edits one or more of them.
1. Markdown content files
Pages and blog posts are usually Markdown files. In Hugo they sit under content/, in Jekyll under _posts/ for posts and in the project root or a folder for pages. The body of the file is the text readers see. Editing a paragraph here is low risk: Markdown is plain text with a few symbols for headings, links and lists.
2. Front matter
At the top of each content file is a block of settings called front matter. Hugo's front matter docs explain that it can be YAML between --- lines, TOML between +++ lines, or JSON, and that common fields include title, date, draft and description. Jekyll's front matter is always YAML between --- lines, and fields like layout, permalink and published change how the page is built.
---
title: "Opening hours"
description: "When our Leeds shop is open, including bank holidays."
draft: false
---Front matter is where most accidental breakage happens. A missing quote or a stray colon makes the YAML invalid and the build can fail. Changing permalink, layout or draft changes the URL, the template or whether the page is published at all. The title and description often become the page title and meta description that Google shows, so treat them as SEO edits. Our guide to SEO-safe edits of titles, H1s and meta descriptions covers that part.
3. Data files
Repeated facts such as the phone number, opening hours, team members or prices are often kept in one data file and pulled into many pages. Jekyll reads YAML, JSON, CSV and TSV files from the _data folder, and a file named members.yml becomes site.data.members in templates, as the Jekyll data files docs show. Hugo has a data directory in the project root that it merges into one structure for templates, described in Hugo's data sources docs.
# _data/contact.yml
phone: "0113 496 0000"
email: "hello@example.com"
hours: "Mon to Fri, 9:00 to 17:30"If your developer set the site up this way, changing the phone number is one line in one file, and it updates everywhere. If they did not, the same number may be typed into five templates.
4. Layouts, partials and config
Hugo keeps templates in layouts/ and site settings in a config file such as hugo.toml. Jekyll uses _layouts/, _includes/ and _config.yml. These files mix text with template code. A footer tagline might sit in a partial next to loops and conditions. This is the zone where a non-developer should ask rather than edit, because one broken tag can break every page that uses the template.
Four ways to edit without a developer
Option 1: The GitHub web editor
If the site is on GitHub, you can open a file in the browser, click the pencil icon, change the text, preview it and commit. GitHub's docs on editing files describe the choice at the end: commit to the current branch, or create a new branch and open a pull request.
For a safer setup, ask your developer to turn on branch protection. GitHub's protected branches docs explain that required reviews mean changes can only reach the protected branch through a pull request, and required status checks can block a merge until the build passes. Then a typo fix in front matter fails the check instead of taking the site down.
Good for: occasional fixes by someone comfortable reading a Markdown file. Weak spot: you have to find the right file yourself, and nothing stops you from editing a layout.
Option 2: A Git-based CMS
A Git-based CMS adds a form-based editor on top of the repository and saves changes back as commits. Decap CMS calls itself "an open source content management system for your Git workflow", stores content in your Git repository, and lists guides for Hugo and Jekyll among other generators. CloudCannon describes itself as a Git-based CMS with visual editing and names Hugo, Jekyll, Eleventy and Astro among the generators it works with.
The trade-off is setup. A developer has to describe each content type and field in a config file so the editor knows what to show. Once that is done, editors get clean forms and a clear boundary between content and code.
Good for: sites with many pages of the same shape (posts, team members, locations) and an agency willing to configure it. Weak spot: anything the config does not model, such as a sentence in a partial, is still out of reach.
Option 3: Move content into data files first
Sometimes the best fix is structural. If the phone number, hours and prices are hard-coded in templates, ask your developer to move them into a data file or front matter once. After that, every option on this list gets safer, because the editable text is separated from the template code. This is a one-time job, and it pays off whichever editing tool you choose.
Option 4: Edit by chat
The newest option is an AI editor that works on the repository. You describe the change ("change our Saturday hours to 10 to 4"), and the AI finds the file, makes the edit and commits it. The risk with any AI editor is that it edits whatever it finds, including template code. The question to ask any tool in this category is what it is not allowed to touch, and what happens when a request crosses that line.
Where CMS Chat fits
CMS Chat connects to your site's GitHub repository through a GitHub App you install on that repo. It scans the repo, maps the editable text, images and links in files like Markdown, MDX, HTML and JSON, and gives each zone a rule: editable, warn, escalate or locked. Routine edits are committed to the default branch, so your host rebuilds the site as usual. Riskier edits arrive as a pull request for the developer, and layout or code changes are not guessed. Titles, meta descriptions and H1/H2 headings ask before they change. The steps are on How it works.
Hugo is one of the frameworks CMS Chat detects by name. Jekyll is not named on the product pages; a Jekyll site is Markdown, HTML and YAML in a repository, but check Connect to see whether your repo is a fit before relying on it. CMS Chat is in early access, and it is not a plugin for another CMS. If you live in Claude or ChatGPT already, the same edits can run there through MCP, explained in edit your website from Claude or ChatGPT.
Which option to pick
- You change one thing a year: use the GitHub web editor, with branch protection and a build check turned on.
- You publish posts or update many similar pages: a Git-based CMS like Decap CMS or CloudCannon, configured by your developer.
- Facts are copied across templates: ask for a one-time move into a data file before anything else.
- You want to type the change in plain words and have risky edits routed to your developer: a chat editor with zone rules, such as CMS Chat.
- You need new sections, new page types or design changes: that is developer work in any setup, and no editing tool should pretend otherwise.
Whatever you choose, keep one rule: content files and data files are yours, layouts and config belong to your developer. Most broken static sites come from crossing that line.
For the wider picture of editing a site you did not build, see how to edit your website without a developer. If your site is built on Next.js rather than a static generator, read let clients edit a Next.js site without a CMS.