Website Migration Checklist for Government and Nonprofit Sites

The single most damaging thing a public-sector or nonprofit website redesign can do is quietly change every URL. Ten years of agendas, minutes, notices, annual reports and grant materials stop resolving on launch day. Residents hit dead links from search results. Funders hit dead links from their own records. And whatever search visibility the old site had accumulated evaporates over the following weeks.

None of that is inevitable. URL preservation is routine work when it is planned into the project and expensive when it is discovered afterwards. This is the checklist we work through, written so you can hold a vendor to it — or run it yourself.

Before anything else: crawl the current site

You cannot preserve what you have not counted. Run a full crawl of the existing site and export the URL list before any design work starts. Count pages and documents separately: 400 pages and 3,000 PDFs is a very different migration from 400 pages and 30.

Pull server logs or analytics for the same period while you are at it. The pages nobody has visited in two years are candidates for archiving rather than migrating, and that decision is much easier to make with data than with opinions.

Decide the content policy before the redirect map

Every URL ends up in one of four buckets, and deciding which is a content decision, not a technical one:

Migrate as-is — the content is current and the URL keeps working. Migrate and rewrite — the content stays but gets rewritten, usually into plain language. Consolidate — several near-duplicate pages become one, with the others redirecting to it. Archive — the content leaves the live site but the URL still needs a destination.

That fourth bucket is where most projects go wrong. "Archive" cannot mean "delete and forget." Statutory retention obligations frequently apply, and even where they do not, a URL that has been cited for a decade deserves better than a 404.

Build the redirect map as a deliverable

Insist on a redirect mapping document, delivered and reviewed before launch rather than assembled afterwards. Every old URL, its new destination, and the redirect type. Permanent redirects for anything that moved permanently — which is nearly everything in a redesign.

Watch for three specific failures. Redirect chains, where A points to B which points to C, should be collapsed so every old URL points directly at its final destination. Redirect loops break the page entirely. And bulk redirects to the homepage are worse than useless: search engines treat a redirect to an irrelevant page as a soft 404, and the resident who clicked a link to a 2019 council packet is now looking at your homepage with no idea where their document went.

Protect the archive specifically

Agendas, minutes, notices, budgets, annual reports and grant materials deserve a separate pass. They are the URLs most likely to be cited externally and least likely to be checked internally, because nobody on the project team visits them.

Pick a sample across years — the oldest, a few from the middle, the most recent — and test each one manually after launch. If your archive is organised by year, test one from every year. This is twenty minutes of work that catches the failure nobody else would notice for months.

Preserve the document URLs too

PDF links break at least as often as page links, and they are frequently the thing that was actually cited. If your documents are moving to a new path structure or a new storage location, they need redirects exactly as pages do.

This is also the moment to decide whether the key content inside those documents should become web pages — better for accessibility, better for search, and better for the residents who are reading on a phone. See Section 508 compliance for why document accessibility usually cannot be ignored.

Carry the metadata across

Titles, meta descriptions and canonical tags do not migrate themselves. Neither does structured data. If the old site had accurate opening hours or event markup, confirm it exists on the new one, or you will lose accuracy in exactly the places AI assistants and search engines read — see GEO for government websites.

Check that any noindex directives from the old site are intentional on the new one, and that no staging-site noindex escaped into production. That last one is common enough to be worth a specific check on launch day.

Do not forget the things that are not pages

Sitemaps need regenerating from the new URL set, not copying across. Robots.txt needs reviewing. Analytics and search console properties need the new site verified. Forms need their handlers tested end to end, because a form that submits into nowhere is the kind of failure nobody notices until a resident complains that they never heard back.

If you use an accessibility statement, a privacy policy or a records-request page, confirm those URLs specifically — they are frequently linked from external legal or compliance documents.

Launch-day and week-one checks

On the day: confirm the site is indexable, spot-check redirects from the sampled archive list, test every form, and check the pages carrying your most-asked facts.

In week one: watch for 404s in your logs and search console, and fix them as they appear. A migration is not finished at launch — the first fortnight of error monitoring is what turns a good redirect map into a complete one, because real traffic always finds URLs a crawl did not.

The short version

Crawl and count first. Classify every URL into migrate, rewrite, consolidate or archive. Deliver a redirect map before launch with no chains, no loops and no bulk homepage redirects. Test the archive by sampling across years. Redirect documents as well as pages. Carry metadata and structured data across. Regenerate sitemaps. Monitor 404s for a fortnight.

If a proposal you are evaluating does not describe this work, it has not been priced — which is worth knowing before you award. Our guide to evaluating proposals covers what else to look for, and we handle this as part of website migration services and every municipal build.