Keeping a Changelog on a Microsite for Long-Term Stewardship
A single-page project, a quiet archive, a side project that lives on a forgotten subdomain—each of these quietly accumulates history. A microsite rarely looks busy, yet it carries the same need for record-keeping that a large publication does. Visitors arriving months later want to know what changed, why a section disappeared, or when a particular essay was last refreshed. That is where a changelog earns its keep, turning silence into a paper trail that anyone can follow.
For a domain like papajohnphillips.com, where the focus is archival material and gentle navigation through old sections, a written record of edits, additions, and removals turns scattered updates into a readable timeline. It also signals stewardship. Anyone landing on the page can scroll through dated entries and see that the site is cared for rather than abandoned. A changelog in this setting is less about novelty and more about continuity, the reassurance that someone is paying attention even when the front page looks unchanged for weeks.
What a Changelog Records on a Small Site
A changelog is not a press release. It is a plain, dated list of what changed on a website, written so that a stranger can follow along. On a microsite this often means noting the addition of a new article, the renaming of a section, the deletion of an out-of-date page, or the correction of a typo that mattered. The point is not to boast about the work but to leave a trail that outlasts the moment of editing.
A reader in Adelaide looking at a historical archive might want to know whether the article they are reading was last updated before or after a known legislative change. A small Melbourne cafe operator who bookmarked a guide last year might return to find that the recommendations have shifted in response to supplier changes. In both cases, a visible change entry removes guesswork and prevents the visitor from acting on stale information.
The changelog also helps the owner. Months after a quiet restructuring, even the person who did the work forgets why a category was merged with another or why an old page was redirected. A two-line note from the day of the change saves an afternoon of investigation later. It also keeps future edits consistent with past decisions, which matters on a site where one person wears the hats of editor, designer, and archivist.
Choosing a Format That Lasts
The simplest approach is a plain text file or a single Markdown page kept at a known URL. It needs no plugin, no database, no special software to read it. Visitors can bookmark it, search engines can index it, and the file can be copied, archived, and downloaded without losing structure. For sites that already use static generators, the changelog becomes another page generated from the same pipeline, which means it never falls out of sync with the rest of the build.
Some owners prefer Git-style headers with categories such as Added, Changed, Removed, and Fixed. Others prefer a chronological journal written in plain sentences. Australian site owners often default to the DD/MM/YYYY date format, which keeps timestamps consistent with how dates are read in everyday life across Sydney, Brisbane, and Perth. Whichever format is chosen, consistency matters far more than elegance. A reader who returns every few months should be able to scan the file quickly and see what is different without re-learning the layout each visit.
A practical middle ground works well for archival sites: a single Markdown page organised by year, with each year containing a flat list of dated entries. Subheadings give the eye a place to rest, and the file stays short enough to read in one sitting. Over time the page grows, but it does so predictably, and old entries can be folded into yearly archive pages without disrupting the present one.
| Format | Best For | Maintenance Cost | Reader Effort |
|---|---|---|---|
| Plain text or Markdown file | Long-lived, minimal sites | Very low | Low |
| Blog-style post per change | Sites with active readers | Moderate | Low |
| Inline "last updated" notes on each page | Content-heavy archives | Higher | Very low |
| Git-style grouped releases | Technical documentation | Moderate | Medium |
The table above is a guide, not a rule. Many microsites blend two of these approaches, for instance a chronological journal on a dedicated page combined with a small "last updated" marker on each archived article. The goal is enough structure that history is searchable, and enough simplicity that the system survives years of neglect. A format that requires willpower to maintain will eventually be abandoned, and the changelog will fall behind reality.
Australian Contexts That Shape the Record
Local conditions nudge how a changelog is written. Time zones matter when entries are timestamped. An entry written at 2am AEDT in Hobart is still 2am AEDT in Hobart, but a visitor in Perth looking at the same timestamp needs to remember the three-hour gap. Owners often annotate timezone explicitly, or simply use AEST for everything outside daylight saving months and accept the small inconsistency during the summer. Either choice is fine; what matters is that the choice is consistent.
Legislation also shapes what gets recorded. The Privacy Act 1988 and the Notifiable Data Breaches scheme require certain disclosures when personal information is mishandled. If a microsite once hosted a contact form and the form was removed because of revised privacy practices, that change deserves a note. Likewise, the .au domain rules administered by auDA mean that ownership and contact details can shift over time, and a changelog entry noting the transition protects the next steward who inherits the archive.
There is also the everyday rhythm of running a small site from an Australian kitchen table. Weekends might mean a quiet hour of edits after a trip to Bunnings, while weekday updates happen in short bursts between school pickup and dinner. A changelog respects that reality because it does not demand regular publishing; it simply receives entries whenever the owner has a moment. That flexibility is one of the strongest reasons small Australian sites keep one, and it pairs naturally with the slow, deliberate pace of a personal archive.
Linking the Changelog to the Sitemap and Discovery
A changelog works best when visitors can actually find it. Many small sites tuck the link into the footer with a label such as Updates or Site History, and that placement is usually enough. Pairing the changelog with a sitemap strengthens discovery further. Search engines and human readers alike benefit from a clear path to dated content, particularly on archival sites where the deepest pages are several clicks away from the homepage. A practical sitemap walkthrough explains how a static site can keep its structure readable without adding bloat to the build process.
Sitemaps and changelogs serve different purposes that complement each other. The sitemap shows what exists; the changelog shows what changed. Together they answer both halves of a returning visitor's question: can I still find what I was looking for, and is what I found still current? On a long-running archive, this pairing becomes the difference between a site that feels alive and one that feels frozen in place.
It also helps search engines. A frequently updated changelog signals that a site is maintained, and the dated entries give crawlers fresh content to index without requiring the owner to rewrite the same essays. For an archival microsite, that low-effort signal of activity is often the only thing that brings a returning reader back through search rather than through a bookmark left to gather dust.
Stewardship Beyond the Original Owner
The most overlooked value of a changelog is what it offers after the original owner steps away. Domains change hands. Interests shift. A site that looks quiet on the surface may still hold useful material for someone who arrives years later. A dated, plain-language record lets a new steward understand what came before, which decisions were deliberate, and which corners of the site were experimental rather than essential.
For readers who treat web archives as part of a wider community of practice, a thoughtful changelog signals that the site belongs to a tradition of careful preservation rather than a single author's fleeting project. Projects that model this approach, including the broader work shared through a community archive, demonstrate how small sites can build quiet trust over time through consistent record-keeping rather than flashy redesigns.
The act of writing a changelog is small. A few lines on a Saturday, a date once a month, a sentence when a page is removed. Over years these entries form a record that no analytics dashboard can match. They tell the story of the site in the voice of the person who kept it, and they hand that voice to whoever reads the page next.
A maintained changelog asks very little and gives back steadily. Start with a single page, date your first entry today, and add the next one whenever something changes. The history builds itself once the habit is in place, and the site becomes easier to trust, easier to navigate, and easier to inherit for whoever comes next.