An editorial style guide for a blog should cover only the decisions your writers make over and over and answer differently each time. For most sites that is one page: heading capitalization, numbers, dates, how product and feature names are spelled, how links are written, and a short list of words you will not use. Everything else belongs to one named external manual that you link to rather than restate. A one-page guide plus a single line naming that manual is a complete system. A forty-page guide is a document nobody opens, which is the same as having none.
A style guide is a decision cache, not a writing course
The reason most guides fail is a category error at the start. They are written as reference documents, so they try to be complete, and completeness is exactly what makes them unread.
A working guide has a narrower job. It stores the answers to questions that have already been asked, so nobody has to ask them again and nobody answers them differently. That is all. It does not teach writing, it does not define good prose, and it does not need a section on what a paragraph is.
That job gives you a hard test for every line you are tempted to add: would two competent writers, handed the same sentence, land in different places? If they would both land in the same place, the rule is not doing any work. If one of them would write “March 3, 2026” and the other “3 March 2026”, it is.
The decisions that genuinely recur
These are the ones that produce inconsistency a reader can see, and they are close to the same list on every content site.
| Decision | Why it recurs | Stated in one line |
|---|---|---|
| Heading capitalization | Every heading on every post, and it shows in search results | Sentence case for H2 and H3, title case for the H1 |
| Numbers | Several times per article | Spell out one to nine, numerals from 10 up |
| Dates and times | Anything with a schedule or a version in it | September 6, 2026. Times as 9 am, not 9:00 AM |
| Serial comma | Every list in every sentence | Use it, always |
| Product and brand names | Writers copy whatever spelling they saw last | WordPress, not WordPress. One agreed spelling for your own product |
| Person and address | Sets the whole register of the site | Second person, “you”. “We” only for the company |
| Spelling variety | Invisible until an archive is read end to end | US spelling, and one named dictionary settles it |
| Link text | Every article, several times | Descriptive anchor text, never “click here” |
| Lists | Constant drift between fragments and sentences | Fragments, no terminal periods, capitalized first word |
| Acronyms | Once per article, decided differently each time | Expand on first use, then the acronym alone |
| Words we do not use | The most-consulted section of any real guide | Yours, and short |
| Images | Every post has one and alt text is skipped | One lead image minimum, alt text describes content not decoration |
Twelve rows. That fits on a page, and every row on it earns its space because writers were already deciding it silently.
The test for whether a rule belongs
Three questions, in this order. A rule needs a yes to all three.
Does it come up repeatedly? Once a year is not a rule, it is a conversation.
Would reasonable writers differ? If everyone already does it the same way, writing it down adds length without changing output.
Is the difference visible to a reader, a search result or an archive read in one sitting? Heading capitalization drift is visible. A hyphenation edge case in a compound adjective, in one sentence, is not.
Then one exclusion that removes most of what bloats a guide: if a general manual already settles it, delegate it. The comma rules, the treatment of titles of works, the capitalization of job titles, quotation marks inside parentheses, all of it has been settled at length by people who do nothing else. Restating any of it makes your guide longer and no more likely to be read, and it introduces a second source of truth that will eventually contradict the first.
Name one external manual, and name its edition
The delegation only works if the fallback is specific. “Follow standard English” is not a fallback. A named manual with an edition is.
The usual options, checked on 2026-09-02:
- The Chicago Manual of Style, 18th edition, published by the University of Chicago Press with 2024 text. The long-form default for publishers and book-length work. The online edition is subscription based.
- The AP Stylebook, 57th edition, covering 2024 to 2026, published by the Associated Press. Built for news writing, which is why it suits blogs with short paragraphs and heavy use of numbers and dates.
- The Microsoft Writing Style Guide, free to read on Microsoft Learn, which its own welcome page describes as replacing the Microsoft Manual of Style. Aimed at writing about technology.
For spelling specifically, name a dictionary rather than a manual, because that is the question writers actually look up. Merriam-Webster is the common choice for US spelling.
This is not a fringe method, it is what the largest documentation operations already do. Google’s developer documentation style guide publishes its reference order openly: project-specific guidance first, then Google’s own guide, then third-party references, with spelling sent to Merriam-Webster.com, nontechnical style sent to The Chicago Manual of Style and technical style sent to the Microsoft Writing Style Guide. Read on 2026-09-02, that page names Chicago’s 17th edition while the current text is the 18th, which is itself the useful lesson: pin the edition you actually own, and re-check it when a new one lands. If an operation that size delegates rather than restates, a team of three has no reason to write its own comma chapter.
The one line that makes a short guide complete
Put this at the top of the page, not the bottom:
For anything not covered here, follow [named manual, named edition]. For spelling, follow [named dictionary]. If that still leaves the answer open, ask [named person], and their answer gets added to this page.
The third clause is the important one. It converts the guide from a fixed document into something that grows only when a real question forces it to, which is the only growth pattern that keeps it short. It also puts a name on the tiebreak, so the question stops circulating.
A guide nobody enforces is decoration
This is where most style guides quietly die. They are written, announced once, saved in a folder, and never referenced again. Nothing about a document makes people follow it, and assuming good intentions is not a mechanism.
Four things make it actually apply, none of which need enthusiasm:
The guide is linked in the brief, not stored in a folder. Every assignment carries the link. A guide a writer has to go looking for is a guide they will not open.
The review pass checks it, and returns the rule rather than the rewrite. When a reviewer fixes style silently, the writer learns nothing and the same fix is needed forever. Sending back “headings are sentence case, see the guide” costs less than rewriting and stops the loop.
Everything mechanical gets moved out of prose. A spelling variety belongs in the editor’s language setting. A banned word belongs in a find and replace or a saved search. A recurring formatting rule belongs in a template. A rule a machine can hold is a rule nobody has to remember.
One person owns the page. Not a committee. Guides that anyone can edit accumulate everyone’s preferences, which is how a page becomes forty pages.
If nobody is willing to own it and check it at review, be honest and do not write it. Write the words-we-do-not-use list, five lines, and stop there. A five-line list that gets used beats a complete guide that does not.
Write it after you have published, not before
A guide written before a site has published much encodes guesses. You imagine the problems, you write rules for them, and the rules you needed are not in there because you had not hit them yet.
The version that works is derived rather than invented. Take ten to fifteen of your own published posts and read them for one thing only: places where two of them do the same thing differently. Not quality, not accuracy, just difference. Three date formats. Two spellings of your own feature name. Headings in title case on four posts and sentence case on the rest. That list, sorted by how often each difference appears, is your table of contents already written.
It is the same discipline behind a post-migration checklist built from what actually broke on your own site rather than a generic one, and if you inherited a messy archive through a platform move, the move is often what put three conventions side by side in the first place. The archive’s edges count too: an inconsistent category and tag vocabulary is an editorial decision before it is a technical one, and it belongs on the guide’s page in the same one-line form as everything else.
After that, one habit keeps it right sized: write the rule the second time you make the same correction, not the first. One correction is a mistake. Two is a pattern, and a pattern is what a guide is for.
What your platform should enforce instead
Some decisions should never be prose at all. The heading levels available in the editor, the required fields on a post, the fixed category list, the image sizes, the templates writers start from: each of these is a rule the platform can hold so that nobody has to remember it. That is the part of consistency a well-shaped content model delivers for free, and it is worth knowing which constraints a setup can actually impose before you settle on a platform for other reasons.
One caution, because the temptation is real: do not change platforms to solve a style problem. Style drift is cheap to fix and a migration is not, and the reasons to stay where you are are stronger than most platform comparisons admit.
What a style guide cannot fix
It will not fix the wrong article being written. That failure happens at the brief, upstream of any style decision, and no amount of formatting consistency rescues a piece that answered the wrong question.
It will not fix unclear thinking. Consistent prose and good prose are different achievements, and a guide only delivers the first.
And it will not survive being treated as a document rather than a habit. The measure of whether yours is working is not whether it is thorough. It is whether anyone opened it this month.
FAQ
How long should an editorial style guide for a blog be?
One page for most teams. If it runs longer, check whether the extra length is decisions your writers actually make differently, or material a general style manual already covers. The second kind should be a link, not a section.
Should I use AP or Chicago for a blog?
Either works, and choosing one and sticking with it matters more than which. AP style suits short paragraphs, news-style headlines and heavy use of numbers and dates. Chicago suits longer-form and more formal writing. If your subject is technology, the Microsoft Writing Style Guide is free to read online and closer to the vocabulary you will need.
Do I need a style guide if I am the only writer?
A short one, yes, because your own decisions drift over months. Keep the mechanical rows: dates, numbers, heading case, your product’s spelling, your banned words. Skip everything about handoffs and review, since there is nobody to hand off to yet.
Where should the style guide live?
Wherever your briefs can link to it directly, in one click, with no login step a freelancer does not have. The location matters far less than the link being in the brief every single time.
How often should I update it?
Not on a schedule. Update it when a correction repeats, when you adopt a new term, and when the manual you delegate to publishes a new edition. A guide reviewed quarterly for its own sake grows for its own sake.