00 Field guide
Five ways to publish, explained plainly.
Each publishing path below has a plain description, the kind of site it suits, a setup checklist and the upkeep it asks for. Read the one that matches your answers, or read them all to compare.
01 Anatomy
A small site moves through four stages
Whatever path you choose, the work follows the same order: write the words and layout, check them, put them somewhere visitors can reach, and then look at the result the way a visitor would.
Three rules that hold for every path
- Use relative links such as guide.html, so the folder still works when it is moved.
- Give every page one h1, a clear title and a short description.
- Test with the keyboard, at a phone width and with scripts switched off before you publish.
02 Publishing path
Plain files
Write the pages in HTML and CSS, keep them in one folder and upload that folder to any web server. Nothing needs rebuilding, and the site keeps working after the person who made it has moved on.
Who it suits
Sites that show content, change rarely and have one editor. Examples include a club notice page, a portfolio or an archive of past events.
Setup checklist
- Choose one folder for the whole site and keep every file inside it.
- Start every page with the doctype, a language, a charset and a viewport tag.
- Link to other pages with relative paths, such as contact.html.
- Keep one stylesheet and, if needed, one script file, both loaded from the page head.
- Open each page from your own computer before you upload anything.
Upkeep
Once a year, follow every link, read each page aloud once and check the dates. Keep a short change note in the folder, so the next person knows what changed and why.
03 Publishing path
Static generator
Write content in a light text format, then run a build step that turns those files into finished pages. The words live in one place, the layout lives in one template, and the output is plain files again.
Who it suits
Sites that change often, such as an archive of guides, a reading list or a newsletter, and where one person is comfortable with a command line.
Setup checklist
- Keep source files and built output in separate folders, and never edit the output by hand.
- Store the project in version control, so every change has a date and a note.
- Run the build on your own computer, then open the result and check it before you publish.
- Write the build command down in a short readme beside the project.
Upkeep
Update the generator on purpose, not whenever a notice appears. Read what changed, rebuild, and check the pages again before you publish.
04 Publishing path
Browser-based editor
A hosted editor lets people change words and images from a web browser. It is useful when several people update the site and none of them wants to work with files.
Who it suits
Sites with a few editors, regular updates and standard layouts, such as a local club, a shared studio or a volunteer group.
Setup checklist
- List who can publish, and remove access as soon as someone steps back.
- Ask how content can be exported, so the words are never trapped inside the editor.
- Check the templates against the standards in this guide, including contrast and heading order.
- Keep a copy of the important pages outside the editor.
Upkeep
Review editor accounts when people join or leave. Preview any changed page at phone width before you publish it.
05 Publishing path
Small server with a database
When visitors sign in, save information or see live data, the site needs a small server and a database. You control the data completely, and you also take on the work of keeping the server updated, backed up and secure.
Who it suits
Sites that must store records, such as a members list, a booking form or a small shop. It suits someone who likes operations work and will keep doing it.
Setup checklist
- Write down what data you collect, why you need it and how long you keep it.
- Apply updates on a schedule, and test a restore from backup before you need one.
- Limit who can reach the server, and use a strong, unique password for every account.
- Publish a plain privacy note that matches what the site actually does.
Upkeep
Plan a regular update window, watch for security notices from the software you rely on, and review who has access every few months.
06 Publishing path
Managed backend
A hosted service provides accounts, data storage and sometimes forms, so you write the site and someone else keeps the running parts healthy. In exchange you accept some limits and an ongoing relationship with the provider.
Who it suits
Sites that need sign-in or saved data, but whose owner would rather not run a server. It is a common fit for small membership sites and community tools.
Setup checklist
- Read the provider's own terms, including how data is exported and how accounts are closed.
- Find out where the data is stored and how visitor information is handled, then say so plainly on your site.
- Choose features you can explain in a sentence, and avoid the ones you cannot.
- Write a plan for moving, in case the service changes or closes.
Upkeep
Check the provider's notices, review the access list each season, and export a copy of the data on a schedule you can keep.
07 Checks
Five checks before any launch
- Follow every link on every page, including the links in the footer.
- Read each page with scripts switched off, and confirm the words still make sense.
- Move through the site with the keyboard only, and check that focus is always visible.
- View each page at a phone width of about 360 pixels, and confirm nothing needs sideways scrolling.
- Check that body text meets the WCAG AA minimum contrast of 4.5 to 1.
08 Glossary
Words used in this guide
- Relative link
- A link such as guide.html that finds its target from the current folder, so the site still works when it is moved.
- Semantic HTML
- Markup that names what each part is, such as a heading, a list or a navigation block.
- Skip link
- A link at the top of a page that jumps straight to the main content, for people who navigate by keyboard or screen reader.
- Contrast ratio
- The difference in brightness between text and the color behind it. WCAG AA asks for at least 4.5 to 1 for body text.
- Reduced motion
- A system setting that asks interfaces to avoid unnecessary movement. Good sites respect it.
- Static site
- A site made of finished files that do not need a server to assemble each page.