# How a Kirksville Small Business Can Archive Its Website Before a Redesign

A real pre-redesign website archive combines a crawlable web capture with CMS/server exports, database and media copies, DNS records, screenshots, external-service notes and verification that the archive can actually be opened or replayed.

2026-09-21


![How a Kirksville Small Business Can Archive Its Website Before a Redesign](https://switchboardtechservices.com/static/images/defaults/articles.webp)

A screenshot folder is not a complete website archive.

Neither is a WordPress export.

A serious pre-redesign capture uses several layers because no single tool preserves the entire public site, server state, database and external integrations.

## Record the archive date and system

Start with a README containing:

- domain;
- capture date and time;
- platform;
- host;
- DNS provider;
- responsible person;
- redesign project;
- known limitations.

A website archive is a snapshot.

Future readers need to know when it represented the live site.

## Create a web capture

WARC is a standard format used for web archiving and is listed by the Library of Congress as a preferred format for web archives.

WACZ is another useful package format.

A WARC/WACZ-capable crawl can preserve:

- HTML;
- CSS;
- JavaScript resources;
- images;
- PDFs;
- links.

That creates a replayable public-web layer.

It does not preserve everything.

## Expect dynamic gaps

Web crawlers may fail to capture:

- forms;
- search interfaces;
- database-driven results;
- streaming media;
- social embeds;
- authenticated pages;
- external APIs.

That is why a crawl is only one layer of the archive.

Test the replay rather than assuming the crawler succeeded.

## Create a static or rendered copy too

A browsable static copy can be useful for ordinary access.

It may be easier for a future developer to inspect quickly.

Again, it may miss JavaScript-generated state or server-side behavior.

The value comes from redundancy between capture methods.

## Take screenshots

Capture representative visual states:

- homepage;
- navigation;
- major service pages;
- contact page;
- mobile layout;
- unusual design components;
- forms.

Screenshots preserve appearance.

They do not preserve underlying text relationships, links or functionality.

## Export the CMS

If the site uses a CMS, export the content and metadata available through that platform.

That may include:

- pages;
- posts;
- menus;
- custom post types;
- SEO metadata;
- taxonomy.

A CMS XML export is not automatically a full server backup.

## Capture the server state when authorized

With host access, preserve:

- database dump;
- uploads/media;
- theme/templates;
- custom code;
- configuration examples;
- redirects;
- rewrite rules.

Keep secrets out of broadly accessible archive copies.

Passwords, API keys and private customer data require separate secure handling.

## Preserve DNS information

Record:

- registrar;
- DNS host;
- nameservers;
- A/AAAA;
- CNAME;
- MX;
- SPF;
- DKIM;
- DMARC;
- verification records.

Do not change DNS merely because you are archiving.

The goal is documentation.

## Record external dependencies

List services the website relies on:

- forms;
- email sender;
- booking;
- payments;
- CDN;
- analytics;
- maps;
- video;
- APIs.

A static archive may show the integration without preserving the external service.

Document that distinction.

## Preserve search-state evidence

Save:

- sitemap;
- robots.txt;
- canonical patterns;
- redirect rules;
- important landing URLs;
- Search Console exports where useful.

This is migration evidence.

It is not the same thing as deciding which pages survive the redesign.

## Verify the archive

Open the captured copy in a clean environment.

Check:

- navigation;
- images;
- CSS;
- PDFs;
- representative JavaScript;
- mobile screenshots;
- database dump presence;
- media archive;
- README.

Record what does not work.

A verified incomplete archive is more useful than an allegedly perfect archive nobody tested.

## Store the archive independently

Keep at least one copy outside the production hosting account.

A backup stored beside the system being replaced shares too much risk with it.

For editorial preservation before redesign, see [How to Preserve Old Website Content Before a Kirksville Business Redesign](https://switchboardtechservices.com/articles/preserve-old-website-content-before-kirksville-business-redesign).

If access is already disappearing, use the emergency workflow in [How to Save a Kirksville Website Before Its Domain or Hosting Disappears](https://switchboardtechservices.com/articles/save-kirksville-website-before-domain-hosting-disappears).

- Categories:
  [Website Repair & Redesign](https://switchboardtechservices.com/articles/categories/website-repair-redesign/)
- Tags:
  [#Web Archiving](https://switchboardtechservices.com/articles/tags/web-archiving/), [#WARC](https://switchboardtechservices.com/articles/tags/warc/), [#Website Redesign](https://switchboardtechservices.com/articles/tags/website-redesign/)

[Articles RSS](https://switchboardtechservices.com/feeds/articles.xml "Subscribe using an RSS reader")

---

Canonical URL: https://switchboardtechservices.com/articles/kirksville-small-business-archive-website-before-redesign/

Language: en-us

Content type: article

Published: 2026-09-21T15:58:00+00:00

Description: A technical website-archive workflow for Kirksville businesses preparing for a redesign.