The guide
Local content cannot be generated, only remembered: plan it from what you already know
The useful local post is the one only you could write, so the honest tool asks you questions and then helps you put the answers on a calendar you drew yourself.
- 72 questions nine content types, eight or more questions each
- 4 January always falls in ISO week 1
- 6 working days back from Friday 11 December lands on Thursday 3 December
- DTEND 20070709 how RFC 5545 ends an event that runs to 8 July
Read the full guide Fold the guide
Every small business that writes for the web eventually types the same request into a search box: give me local content ideas. What comes back is a list that could have been written about anywhere. Ten things to do in your city. A guide to the farmers market. A post about the weather. None of it is wrong, and none of it is yours.
The trouble is not a lack of imagination. A list of ideas about a place has to contain facts about that place, and whoever writes the list either knows those facts or makes them up. A page that offers to generate local ideas from a postcode and a trade has only two honest outputs: a template with blanks, or a question.
The knowledge is already in the building
Think about what a heating engineer, a florist or a bicycle shop actually knows. They know which week the phones start ringing. They know which street has the old pipes, which school changes its hours in September, which supplier is open on a Sunday. They know the question a customer asks just before saying yes, and the myth they correct twice a week. That is the material a useful local page is made of, and it does not exist in any database.
The plain language guidance published by the US government’s Digital.gov makes the same point from the reader’s side. People come to a page to do something specific, and writing works when it is aimed at a specific audience who needs it. The Small Business Administration asks for the same discipline in a marketing plan: describe the audience in detail, and revisit the plan at least once a year. Both are reminders that the useful part is particular, not general.
So the honest substitute for idea generation is a good question. Not “write about your area”, which produces the same bland list, but “what do customers in this area ask in the first cold week?” Only the person who answers the phone can answer that. Their answer is already half a post, and it is true, because it came from their own week.
The planner on this page carries nine kinds of content, each with eight or more such questions. They cover how the work is done, a local guide, an event or season, a customer question, behind the scenes, community and partners, a problem and its fix, a note about a place or its history, and data from the business’s own records. That is 72 questions in all, written for the page. None of them can be answered from a map.
From an answer to an idea
An answer is not yet an idea. It becomes one when four things are written down beside it: a working title, the person it is for, the single useful thing it will contain, and a source the writer can point to. That last field matters more than it looks. A post about the hard-water crust on Sample Street taps can rest on the business’s own invoices, which nobody else has. A post about when the street was built has to rest on something outside the business, such as a local history society, and that claim has to be checked before it goes out.
Permission belongs on the same list. A photograph of a neighbour’s shopfront, a quote from the organiser of the street fair, the name of a partner business: each of those is someone else’s, and asking first is part of the work rather than an afterthought. The planner keeps two plain switches on every idea, facts checked and permission noted, so that an unchecked idea looks unfinished on the board until somebody has done the asking.
Effort is the fourth note, and it is deliberately rough. Small, medium or large is enough to stop a busy month filling up with three large pieces. The point is not to estimate hours; it is to see, at a glance, that December holds a feature that needs interviews and photographs during the one month nobody has time.
Duplicates creep in the same way. Two people, or one person on two different days, will write “How to bleed a radiator before the first cold week” and “How to bleed radiators before the first cold week”. The planner compares titles with the Dice coefficient over pairs of letters: twice the number of letter pairs the titles share, divided by the pairs in both. Wikipedia’s own worked example gives 0.25 for night and nacht. It measures similar wording, not similar meaning, and it says so.
A year worth drawing once
Most of what makes a business local is a calendar. Seasons of the trade, school terms, the street fair, the week the clocks change, a stretch of spring storms that floods the same cellars every year. None of these come from a holiday list, because holidays and local events differ from one town to the next and move from year to year. They come from the people who live through them, so the planner ships with no holiday or event data at all. You add your own moments as date ranges, mark which repeat every year, and mark the ones when the business is too busy to write.
Once those moments are drawn, the year starts to explain itself. A publish date in the middle of the busiest weeks stands out. A run of empty months stands out. The first time you see your own year laid out as twelve small grids, the gaps are usually more instructive than the ideas.
Week numbers need a rule, and there is more than one. Under ISO 8601 a week starts on Monday and week 1 is the week that holds the year’s first Thursday, which is why 4 January always falls in week 1. Near New Year a date can belong to the other year’s week: 1 January 2027 is a Friday, so under ISO rules it sits in week 53 of 2026. Many places start the week on Sunday and count week 1 as the week that holds 1 January, which puts the same day in week 1 of 2027. Browsers publish both numbers through Intl.Locale’s getWeekInfo. The planner lets you choose.
Planning backwards from a date
A publish date is the end of a piece of work, not the start. The useful number is the day the work has to begin, and it is found by counting back. The planner counts back one day at a time from the publish day, which is not itself counted, and can skip whatever days you call the weekend.
Here is a worked example you can reproduce on the page. The example plan publishes “Frozen pipe first aid for the year-end shutdown” on Friday 11 December 2026 with 6 working days of preparation and Saturday and Sunday skipped. Counting back gives Thursday 10, Wednesday 9, Tuesday 8, Monday 7, then past the weekend to Friday 4 and Thursday 3 December. Preparation therefore starts on Thursday 3 December, in ISO week 49.
The same example marks a moment called “First cold snap rush” as busy from 2 November to 18 December, so the planner lists a clash: the preparation window sits entirely inside the rush. Moving the post to October, or writing it in the quiet weeks of September, removes the clash without changing a word of it.
Edge cases are where date arithmetic usually breaks, so the planner’s checks cover them. Counting back one day from 1 March 2024 lands on 29 February, and from 1 March 2025 on 28 February. A five working day count from Friday 2 January 2026 crosses the year and lands on Friday 26 December 2025. A yearly moment that runs from 24 December to 2 January appears twice in a plan year, once at each end, because it straddles both New Years.
The calendar file follows the iCalendar standard, RFC 5545, and one sentence of it decides whether an all-day event shows on the right days: the DTEND property of an event is its non-inclusive end. The RFC’s own example is an event from 28 June to 8 July 2007, written with DTEND 20070709, the day after it finishes. Write the last day instead and every calendar program shows the event a day short. The planner’s tests include exactly that mistake to prove the check notices it.
Checking before publishing about neighbours
What the planner cannot do is the part that matters most after the planning. It cannot tell you whether the history society’s date is right, whether the fair’s organiser is happy to be named, or whether a figure from last winter’s job log means what you think it means. It holds a reminder beside every idea and leaves the checking to the person who can pick up the phone.
It also cannot promise readers, rankings or sales, and it does not try. Every count it shows, ideas per type, ideas per month, clashes, empty months, comes from the rows you typed. When you export, the ideas go out as a CSV file built the way RFC 4180 describes. A quote mark goes in front of any cell a spreadsheet might read as a formula, a defence OWASP lists while warning that none works in every program.
Nothing you type is sent anywhere. Saving is off until you switch it on, and then the plan stays in this browser, in IndexedDB where the browser offers it. Delete all is always on the page.
A year of local content is mostly a year of noticing. The planner’s job is to ask the questions that make the noticing easy, then hold the answers on a calendar long enough for them to be written.
Sources
Every source consulted for this guide. Links checked October 21, 2026.
- Principles of plain language Digital.gov, U.S. General Services Administration
- Writing for understanding Digital.gov, U.S. General Services Administration
- Manage your business U.S. Small Business Administration
- ISO week date Wikipedia
- ISO 8601 Wikipedia
- Intl.Locale.prototype.getWeekInfo() MDN Web Docs
- RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar) IETF, RFC Editor
- RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files IETF, RFC Editor
- CSV Injection OWASP Foundation
- IndexedDB API MDN Web Docs
- Dice-Sorensen coefficient Wikipedia