A cassette edition sells out, but the label’s order page still takes payment. A venue moves a performance to another room, while its old address stays on the contact page. Neither failure takes the site offline. Both leave visitors acting on information that looks current. Routine maintenance catches these problems before a listener, customer or performer has to point them out.
For a small independent music project, a website is often an archive, a current catalogue, an events noticeboard and a way to get in touch. Maintaining it is not the same as redesigning it. The job is to keep its records accurate, its software supported and its essential functions working.
The cost of a site that merely appears to work
A site can load quickly and still fail at the point that matters. An inquiry form might show a success message without delivering the email. A download could lead to the wrong file. An embedded track may play on a desktop browser but fail on a phone. Each problem creates avoidable correspondence, if anyone notices it at all.
Stale information causes quieter trouble. Visitors may rely on shop hours, shipping terms or stock claims that no longer apply. On a journal, a broken audio reference can make a piece of criticism harder to follow. Maintenance protects the meaning of the content, not just the sales process.
Accessible, useful pages may help search visibility, but traffic alone is a poor guide to what needs fixing. A contact page with few visits may be where a distributor sends a time-sensitive message. Prioritise pages by the consequences of failure, not just their view counts.
Maintenance has four different jobs
Keep the record accurate
Check the details that change: prices, availability, event times, personnel, addresses, contact routes and fulfilment policies. A sold-out edition can remain in the archive without remaining purchasable. Keep its release page, but make clear which information belongs to the original release and which ordering options are current.
That does not mean rewriting every old statement. A review describing an event as it was at publication is part of the record; a shop notice saying that same event is next week is a live claim. Keeping dated editorial material separate from operational details avoids turning maintenance into silent revision.
Keep the software dependable
Content-management systems, themes, plugins and server software need updates for security and compatibility. Make changes deliberately rather than pressing every update button at once. Take a recoverable backup first, note what changed, then test pages that depend on the affected components. A checkout extension warrants more careful testing than a decorative widget.
Remove extensions you no longer use. Each one adds another possible dependency, conflict or account permission. Review access at the same time: former collaborators should not keep publishing or administrator privileges indefinitely. Give people individual accounts and suitable permission levels, and use multi-factor authentication where available.
Keep essential paths working
Test what visitors actually try to do. Submit the contact form and check that the message arrives. Play an embedded track on a phone. Complete a test order through the payment flow, using test mode if the platform offers it. Check that confirmation emails arrive and that a download opens. A homepage check will miss failures further along the path.
Make accessibility part of the routine. Check that keyboard navigation works, informational images have useful alternative text, and new text remains readable on mobile. This is no substitute for a full accessibility assessment, but it catches mistakes introduced during ordinary publishing.
Keep a way back
A backup needs to contain the files and database required to restore the site. It also needs to live somewhere a failure of the site will not destroy it. Set a schedule that reflects how often content or orders change, and periodically test a restore in a safe environment. A success notification does not prove the recovered site works.
Document where the domain is registered, who controls hosting and what to do if the usual maintainer is unavailable. Store those details securely where the responsible people can reach them, rather than on a public page or in one volunteer’s memory.
A schedule that matches the risk
There is no need to inspect every page each morning. Check frequently changing details more often, especially where an error could affect an order or send someone to the wrong place. A small music business could start with this schedule:
- After every publication or stock change: check the new page, purchase status, credits, audio and links in the relevant catalogue or index.
- Weekly: test contact delivery and active sales paths; check upcoming event details, backup results and alerts from the host or site platform.
- Monthly: review software updates, user accounts and broken internal links, then check a sample of important pages on mobile.
- Quarterly: test a backup restore, revisit shipping and contact details, and inspect older pages that still bring in orders or inquiries.
These intervals are starting points. Daily orders call for closer transaction checks than a static artist archive. A project that publishes monthly can check each page as part of publication. The question is whether a fault will be found before several visitors have to deal with it.
Assign ownership, not just tasks
A checklist without an owner can sit unread. Decide who checks content, who handles software updates and who can authorise a change when the usual maintainer is away. One person may cover several roles on a small team, but the responsibilities should be explicit. Keep a short log of dates, changes, test results and issues left for later.
When time is tight, deal first with exposed security risks, then broken payments or forms, then inaccurate details that could misdirect someone. Less urgent presentation problems can follow. A layout flaw matters, but it should not take precedence over an order confirmation that never arrives.
For a first ten-minute check, send a message through the public contact form from a device you do not use to administer the site. Confirm that it reaches the intended inbox, that the reply address works and that the form does not expose private recipient details. Write down the result and date; the next check will have something firmer than memory to compare against.