An old link to a Finnish thrash demo listing should not go dead because the archive has a new design. Before choosing fonts or rearranging the homepage, list the pages, files and addresses that readers already use to trace the music's history. A redesign can damage an archive just as its material is being made easier to find.
For an independent music archive, momentum is not just traffic. It is the editor publishing a corrected sleeve credit, the collector sending a scan, and the listener following a band from its early recordings to later releases. The site should become easier to use without interrupting those exchanges. That takes a controlled change, not months of silence followed by a reveal.
Define what the redesign needs to fix
Start with problems you can see. Maybe release entries bury the format and year beneath a long introduction. Maybe gig photographs obscure their captions on a phone. Or two entries for the same Finnish band use different names, leaving readers unsure whether they have found the full discography. These problems call for different fixes; none automatically calls for a new visual design.
Write a short brief with three columns: the problem, evidence, and what would count as an improvement. Evidence might include repeated reader questions, broken internal links, an editorial backlog or a mobile page that requires horizontal scrolling. If readers struggle to distinguish a demo cassette from a later reissue, a consistent release-information block may help. “Make the site feel modern” gives neither an editor nor a developer a usable test.
Keep the scope visible. New navigation and a release template may be needed for launch; rewriting every historical account may not. Decide what must be done now, what can follow, and what belongs in a separate research project. A better structure does not require treating old pages as disposable.
Take an inventory before changing the structure
The page inventory is your working map. Record each current URL, page type, title, publication status and intended destination. Include band profiles, release entries, interviews, concert reports, photo pages and any downloadable material the archive is entitled to host. Flag pages with useful comments or citations: their value may not be obvious from the homepage.
Mark each item retain, revise, merge, redirect or retire. Do not delete a thin page simply because it is thin; it may hold the archive's only documented reference to a small independent release. On the other hand, two near-identical profiles may work better as one entry with a note about alternate band-name spellings. Where provenance is uncertain, keep that uncertainty visible rather than turning it into an unsupported fact.
Look beyond the main text. Caption credits, image permissions, scan descriptions and links from a concert account to its source all need a place in the new site. If they live in a theme-specific field, work out how to move them before committing to a template. Our guide to keeping a Finnish thrash archive accurate covers the ongoing record work; during a redesign, the immediate concern is getting those records across intact.
Protect the routes people already use
Old URLs turn up in bookmarks, forum discussions, review citations and messages between collectors. A new menu does not require new URLs. Keep established band and release addresses where possible. When an address has to change, set up a permanent redirect to the closest relevant new page.
Make the redirect map before launch, not after readers start reporting errors. Pair each old URL with its destination, then check that the destination contains the information a reader came for. Sending every retired release page to the homepage may conceal a broken route, but it will not help someone looking for a particular cassette. Avoid chains that send an old address through another old address before reaching the new page.
Check links within the archive too. Interviews and discography notes may still point to old pages even if the menu works perfectly. Follow a few routes a reader might take: band profile to demo entry, demo entry to documented concert account, then back to the band. The archive depends on those specific connections, not just a tidy menu.
Keep publishing while the rebuild proceeds
A content freeze planned for “a few weeks” can quietly stretch into months. Keep the live site as the public record during the rebuild, and set a narrow freeze window close to launch. Log anything added or corrected while the replacement is being built.
The log need only capture the current page URL, date of change, description, responsible person and whether the change has reached the new version. Suppose a reader sends a corrected track title during development. Without a log, the live entry may be fixed while the replacement goes out with the old mistake. Compare the versions before switching over and clear any outstanding changes.
A small volunteer archive may find it easier to redesign one page type at a time. Build a band-profile template, move a few contrasting entries, and test them before migrating every profile. A short-lived band with one independently issued recording needs different space from a group with several releases and documented European dates. Try both, or the template may suit only the fullest entry.
Set a realistic weekly rhythm
- Reserve time for the live archive. Keep up essential corrections and replies to source submissions, even if new long-form features slow down.
- Separate research from migration. Moving a verified release date into a new field is migration. Investigating an uncertain date is research and may take longer.
- Close small batches. Finish and check a manageable group of pages before opening the next, rather than leaving dozens half-moved.
- Record decisions. Note why a page was merged or a title retained. The next editor will face similar cases.
Design for the questions the archive can answer
Lettering and high-contrast artwork can evoke classic thrash, but readers must still be able to find the essentials: release format, recording period when documented, verified personnel credits, and whether an item is an original issue or a later edition. Typography and artwork should make those distinctions clearer, not harder to read.
Give each page type a predictable shape. A release entry might put its title, artist, format, year and evidence notes in consistent places. A concert account might distinguish advertised billing from an independently confirmed performance. Captions should state what the archive knows and credit contributors where appropriate. Consistency helps readers, while making missing information easier for editors to spot.
Design with actual material rather than idealized filler. Try a long band name, a low-resolution flyer whose text matters, a record with conflicting dates and a page without a usable photograph. An underground archive cannot assume every entry has a sharp cover image and a complete biography. For detailed performance decisions, the post on page speed for music archives looks at keeping that material accessible without making pages heavy.
Give the work a clear decision path
Even a two-person project needs clear responsibilities. Decide who approves navigation changes, checks historical claims, handles image rights and publishes the finished site. A designer should not have to guess whether an uncertain concert date can be stated as fact. An editor should not learn on launch day that captions were left behind because nobody was assigned to move them.
Track open decisions in one place, with an owner and a deadline for each. Separate launch blockers from work that can wait. A missing redirect for a well-linked band page is a blocker; spacing around a secondary heading usually is not. Otherwise, small refinements can stall the project while important routes go untested.
Once implementation starts, ask that new requests identify the problem they solve and their effect on the schedule. A newly found error still needs attention, but it needs a decision: fix it on the live site, carry it into the new build, or set it aside for later research. Volunteer time is limited.
Test the archive as a reader would use it
A staging site lets editors inspect the replacement without exposing unfinished pages to readers. Keep it out of casual search indexing and make clear that the live site remains the authoritative copy. Testing goes beyond seeing whether a page loads: look for missing credits, cropped flyer text, unclear date labels, broken audio descriptions and links to the wrong release.
Use a phone as well as a desktop. Release-format tables can become unreadable at narrow widths, and a long menu can bury the band index. Check keyboard access and descriptive link text, especially on pages with many similar entries. The overview of web accessibility provides background; the practical question is whether readers can reach and understand this archive's material.
Ask a few readers to try specific tasks without coaching: find a band's earliest documented release, tell an original cassette from a reissue, or locate evidence for a disputed detail. Write down the task and where they hesitated. That will tell you more about the structure than a general opinion of the new look.
Before launch, run a short acceptance checklist:
- Open a sample of old URLs and confirm that each goes directly to the intended page.
- Compare migrated entries with the live versions for dates, credits, captions and source notes.
- Check the main page types on narrow and wide screens.
- Submit the contact or correction form and confirm that the message reaches the right person.
- Verify that private drafts and the staging site do not appear as public archive entries.
Launch in a way that leaves room to correct mistakes
Launch when someone can watch the site and fix problems promptly. Back up the live site and its media, and agree on how to restore them if something serious fails. Keep the inventory and redirect map at hand; they are useful diagnostic tools once the new design is public.
After the switch, check established band pages, release entries cited elsewhere, the archive index and the contact route first. Look for missing files, unexpected 404 pages and submissions that no longer arrive. No complaints does not mean all is well; a reader who hits a dead end may simply leave.
Publish a brief note about practical changes, such as a reorganized discography or a new way to submit corrections. Do not call the archive complete if research remains in progress. Returning readers need to know what moved and how to keep contributing.
Keep a small post-launch queue apart from the main research backlog. For each issue, record the affected URL, what the reader expected, what happened and whether the fix was checked on the live site. If an old demo link reaches the right band but the wrong edition, point its redirect to the original demo entry. Then open the old address again and check where it lands.
