A dated homepage is rarely reason enough to rebuild a music site. A reader who cannot find a review by artist name, a label unable to use the contact form on a phone, or an editor rebuilding the same layout for every new piece: those are harder to dismiss. The first question is whether a few pages need repair or the trouble sits in the structure beneath them.
For a publication covering noise, ambient, drone, electroacoustic work, and cassette culture, the site serves as both current issue and long-lived archive. A redesign might make years of writing easier to reach, but it can also break routes readers, artists, and other writers already rely on. The likely gains need to be specific enough to weigh against that risk.
Separate a redesign from routine maintenance
Calling every change a redesign makes the decision harder. A cramped typeface, poor contrast, or broken form may need no new architecture. A review template might need substantial work without any change to navigation. A full redesign reaches further, into page templates, navigation, content structure, and the way articles are found or published. Changing the publishing platform may be part of that work, but it is not a requirement.
Start with a problem log, not a mood board. For each complaint, note the page, what someone tried to do, what happened instead, and how often it happens. An editor's frustration with the homepage counts as evidence; articles held up by a brittle publishing tool make a stronger case. Keep observations apart from guesses. Falling search traffic, for example, does not establish that design is the cause.
Problems that may need only a local fix
- One unclear label: Rename the navigation item, then check whether people can find the destination.
- A handful of unreadable older pages: Repair their formatting and shared article styles before replacing every template.
- Oversized photographs: Improve image preparation and compression before treating a speed complaint as grounds for a rebuild.
- A broken submission path: Fix the form, its confirmation message, and its fallback contact method first.
Minor repairs do not add up automatically to a redesign. But if the same template, navigation system, or publishing tool keeps recreating the trouble, the case changes.
Look for failures that run through the site
A stronger case emerges when the publication has outgrown its website. A site built for occasional posts may now hold hundreds of reviews, interviews, listening guides, and reports. Readers need to tell a review from a festival report and move between related artists or labels. If those distinctions depend on improvised tags and hand-added links, fresh styling will leave the underlying problem untouched.
Navigation offers another clue. A reader reaches a review of a Japanese drone release and wants to find writing about the artist's earlier work. If a general search box full of unrelated mentions is the only route, changing the menu color will do little. First, identify the routes people use: search results, artist names, dates, categories, and links within articles. The point is not to put every classification on the homepage. It is to make the next useful step visible where the reader lands.
Accessibility can expose defects shared across the site. If keyboard focus disappears across templates, headings are chosen for their appearance rather than their meaning, or menus require a mouse, article-by-article fixes will not solve it. The general principles in Wikipedia's overview of web accessibility offer context; the redesign brief still needs evidence from the site's own pages. Name the unreachable control, the confusing heading sequence, or the task someone cannot complete.
Then look at editorial labor. A layout that requires custom code for audio notes, a track list, or a long quotation quietly takes time from publishing. When several recurring formats rely on workarounds, better templates may give editors more time to listen and check sources than a visual refresh would.
Gather evidence before choosing a scale
The audit need not be elaborate. Choose pages that reflect what the site publishes: a recent review, an older one, a long interview, a guide, a category page, and the contact page. Include pages with steady visits alongside those editors consider important. Try them on a phone and with a keyboard. If possible, ask someone unfamiliar with the site to carry out ordinary tasks without coaching.
Tasks worth observing
- Find a review by artist name rather than its exact title.
- Move from that review to another relevant piece without going back to a search engine.
- Find the publication date and any correction or update notice.
- Find a working contact route for a correction or editorial pitch.
- Read a long article on a narrow screen without losing track of headings or captions.
Note where a task stalls, not just whether it succeeds. Finding a review after four search attempts is different from finding it straight away. On the other hand, a visitor's hesitation over a specialist term may call for clearer wording, not a rebuilt archive.
Site data can help, provided it is read carefully. Search queries may show that readers look for artist names the navigation does not expose. Visits to older pages show which URLs need particular protection. Repeated exits from a form page warrant a closer look, but they do not prove anyone tried and failed to submit it. Check the numbers against direct observation and editorial experience; look for a pattern supported by more than one source.
Estimate what the redesign would put at risk
An independent music archive is worth more than its current appearance. Old URLs may appear in artists' biographies, label notes, forum discussions, academic references, and personal reading lists. A platform change or new permalink scheme without a complete redirect plan can cut off those references. Before approving a redesign, export the existing URLs and mark pages whose titles, paths, or content types may change. Decide who will test the redirects and what happens when a page has no direct replacement.
Estimate migration separately. Older articles may have inconsistent headings, missing captions, obsolete embeds, or formatting carried over from previous editors. A new template will not repair them automatically. Sample articles across years and formats, then record the cleanup each requires. If twenty sampled pages reveal several different problems, migration is unlikely to be a single afternoon's work.
There is an editorial cost, too. Weeks spent moving pages can delay reviews, interviews, or archive research, even if volunteers handle the technical work. Name who will approve layouts, check migrated copy, test forms, and respond to problems after launch. If every job falls to one already overextended editor, the scope is too large.
Be cautious with features no one can maintain. Detailed filters need consistent metadata. Custom audio players need testing and upkeep, including when an external recording disappears. For a cassette review, a readable article with clear credits and a stable link may be more useful than an ambitious interface that breaks when a dependency changes.
Choose the smallest intervention that resolves the pattern
Once the audit is done, sort findings by scope. A real problem should not become an excuse to replace parts of the site that work.
| Observed pattern | Likely first intervention | Reason to expand the scope |
|---|---|---|
| Readers cannot identify the next relevant article | Improve article-level links and labels | Categories and metadata cannot describe relationships consistently |
| Long pieces are difficult to read on phones | Revise typography and article templates | Shared layouts or navigation also fail across mobile pages |
| Editors repeatedly rebuild standard elements | Create reusable publishing patterns | The platform cannot support them reliably |
| Older pages break after routine updates | Investigate the technical cause and repair affected templates | Core dependencies are no longer maintainable |
These are starting points, not diagnoses. Several problems may share a cause that calls for a substantial rebuild; a few targeted changes may also solve most of what readers encounter. Either way, write down what will stay. A working URL scheme, article chronology, and familiar archive routes deserve protection.
If a full redesign is justified, define success as a task, not an adjective. “Cleaner” and “more modern” cannot guide a test. “A reader can find all reviews of an artist from the first review they open” can. So can “An editor can publish a standard review without custom markup.” Decide how to check those outcomes before approving a mockup.
Plan the redesign around content, not a homepage sketch
Work with representative material: a short announcement, a long interview, a review with detailed recording credits, and older posts with no suitable image. Each puts different demands on a template. A polished homepage can hide failures until migration is well underway.
Set out what must remain legible and findable on every article: title, author, publication date, relevant credits, and any correction or update notice. Work out how to distinguish an artist from a label without forcing either into the wrong category. Experimental music archives contain collaborations, aliases, installations, and performances that do not always fit neat classifications. The data model should leave room for uncertainty instead of asking editors to invent precision.
Test technical ideas against the work of publishing. Search is useful only if it indexes the fields readers look for. Categories help only if editors can apply them consistently to new articles and reasonably migrate old ones. An audio embed needs surrounding text so the article still makes sense when playback is unavailable. Where names, labels, or titles use different scripts, test display and search with them; a mockup alone will not answer those questions.
Build a staging version and repeat the audit tasks on it. Use migrated articles, including awkward ones, rather than demonstration content alone. Check keyboard use, narrow screens, broken images, missing embeds, forms, search, and page titles. Make sure old URLs lead to the intended pages. A site that looks finished but fails these checks is not ready to replace the archive.
Know when to postpone it
There are good reasons to wait, even when a redesign seems warranted. If the team cannot say which readers are struggling or which workflows fail, investigate first. An incomplete content inventory makes migration estimates unreliable. And a platform no one can maintain after launch is likely to create a fresh set of problems.
Waiting does not mean leaving known barriers in place. Repair a broken contact route, unreadable text, or an inaccessible menu as soon as practical. Those fixes can sharpen the diagnosis: once an obvious defect is gone, it is easier to see what remains. A phased project can then start with the article template or archive structure causing the most trouble, rather than replacing every page at once.
Before launch, take an older review with an established URL through the new site. Open its previous address, check the redirect, inspect its credits and date, find it through search, and follow a related-article link. One page cannot validate an entire archive, but it can reveal several failures while there is still time to fix them.