After Website Restoration: The SEO and QA Checklist (Links, Canonicals, Sitemap, Handover)

A restored website can have every page back and still be in poor shape for search. Links can point at web.archive.org, canonicals can name a staging host, the sitemap can list addresses that redirect, and the owner can be handed a login without knowing what was delivered. This guide consolidates the checks we run after a restoration: acceptance scope, internal links, canonicals and redirects, the sitemap, multilingual relationships, static HTML deployment, and how to measure whether search visibility is coming back.

It applies to any rebuild, whether the result is a static package from our HTML website restoration, an editable site from WordPress restoration or Elementor restoration, or a store from ecommerce restoration. For what the archive can and cannot supply in the first place, see What the Wayback Machine Can and Cannot Recover. For store-specific checks, see Rebuilding an Online Store from the Wayback Machine.

Start with the acceptance record, not the homepage

Compare the delivered site with the agreed scope, not with an old screenshot. A convincing homepage tells you nothing about omitted articles, missing documents or historical URLs that still fail. Give every agreed requirement a result before you look at anything else.

Ask for the agreed page list, the delivery format, the editing method, the included functions and the known source limitations. Give each item one of four results: verified, unresolved, outside scope or approved exception. “Done” without a destination and a check result cannot be reviewed later.

Compare accepted pages against the source inventory and distinguish content restored from public evidence, content reconstructed from partial evidence, and new content written to fill a gap. A count of files is not a count of complete pages. Open representative long pages, confirm the text ends where it should, and check that old offers and contact details were reviewed with the owner.

For each important item, record the requirement and expected destination, the supporting source or approved replacement, the check performed and its date, the remaining gap, and the responsible person. Then test the important paths logged out at the exact agreed public URLs, not through an administrator preview. A page can work from the new navigation while its historical path still fails, and a redirect to the homepage is not a successful restoration of a specific page.

Audit internal links as relationships, not status codes

An internal-link audit checks where every navigation and contextual link leads, whether its label matches the destination, and whether important pages remain reachable. Two pages can both return 200 and the link between them can still be broken, because the label promises something the destination does not supply.

Collect links from page content, navigation, footer and linked images. For each, keep the source page, the visible label, the requested destination and the final result after redirects. A crawl gives you discovery evidence, but compare it with the approved page inventory: a page missing from the crawl may be missing, inaccessible, or simply not connected from the routes you tested.

Then verify meaning. Consider an article that says “download the installation checklist” while its restored link opens the services homepage. Both pages load; the defect is the relationship. Find the original checklist and its approved address, repair the reference if it survives, and otherwise ask the owner whether to revise the sentence or supply a new resource. Do not mark the link fixed because it no longer errors.

Look for duplicates introduced by reconstruction, such as an HTML file and a WordPress permalink showing the same material; decide which survives from established ownership and the canonical plan, not from the filenames. Find orphans, pages with no incoming internal link, and reconnect the useful ones from a related article rather than a giant footer list. Keep accurate anchor text, correct only misleading or empty labels, and avoid repeated commercial anchors inserted to target keywords.

A short pass/fail list for restored sites:

• Every important page receives links from at least one relevant page, not only from the menu.
• No internal link points to web.archive.org, the old domain or a staging host.
• Internal links point straight at the final address, not at a redirecting one.
• No internal link leads to a page that returns an error.
• Anchor text describes the destination clearly.
• Service and contact pages are reachable within a few clicks from the homepage.

Repair essential navigation and conversion paths first, then misleading links and missing downloads, then orphans, then duplicates and redirect chains. Record before and after references; a link audit does not authorize redirects, content removals or URL changes. After each repair, retest logged out, including mobile navigation where a relationship depends on a collapsed menu. A crawler export sorted by status finds broken and redirected links fastest, and Search Console’s internal link counts are a useful cross-check.

Make canonicals and redirects agree with the approved URL map

A canonical tag tells search systems which version of a page you prefer; it does not move the visitor. A redirect moves the visitor. Neither should be used to replace original URLs that can be preserved, and the two must not contradict each other or the sitemap.

Start with the variants that actually occur: scheme, hostname, trailing slash and meaningful parameters. Record what each returns and where it redirects. Do not assume visually similar addresses are equivalent; a parameter can select different content. A downloader’s new filename is never automatically the preferred public URL.

Read the canonical output at the live address, logged out, in the HTML and, for PDFs and other non-HTML documents, in the HTTP Link header. Note whether each target names the approved public page, a staging host or an archive address. If several mechanisms emit conflicting canonicals, find the source before changing anything. On WordPress the canonical usually comes from the SEO plugin, while redirects may come from a redirect plugin, server configuration, the host’s control panel or a CDN on top. A redirect fixed in a plugin can still be overridden by a server rule, so change the responsible layer and retest from outside the network.

Trace redirects separately: record every hop from each original address to its final destination, watching for loops, chains and irrelevant landing pages. A final 200 must also contain the intended content. Do not redirect every old URL to the homepage; redirect each to the page that best matches its content, because mass homepage redirects are commonly treated like missing pages.

The patterns worth checking first after a rebuild:

• Canonicals copied from the archive that still reference web.archive.org or an old domain.
• Canonicals pointing at a URL that itself redirects, and redirect chains of two or more hops.
• http and https, or www and non-www, both responding without redirecting to one version.
• Trailing-slash inconsistency between links, canonicals and the sitemap.
• Paginated or filtered pages canonicalized to page one when their content is distinct.

For each important page, write down four things: the address links use, the final address after redirects, the canonical on that final page, and the address in the sitemap. When all four agree, the page sends one consistent signal; when they differ, decide which is intended and change the others to match. Do not reach for a broad robots block, a noindex change or an SEO-plugin reset to fix a narrow canonical defect. A correct canonical does not guarantee indexing.

Rebuild the sitemap from the verified page inventory

Build the sitemap from the approved list of restored pages, not from every address found in the archive download. Then check each entry against its actual response and canonical. Submission is a discovery hint; it does not prove that any page is indexed.

Define the eligible set first: public published content only, excluding drafts, test copies, thank-you pages, search results and any archive replay or staging URL. Then compare in both directions: which approved pages are absent, and which sitemap addresses do not belong? A raw count cannot answer either question. An inventory containing /guides/recovery/ and a sitemap containing /guides/recovery.html can have the same total and still disagree, and the fix is to correct the generation, not to rename the article.

Use modification dates honestly. Keep capture dates in your provenance record, but do not copy them into lastmod or set every page to today’s date. Google uses lastmod when it is consistently accurate and ignores priority and changefreq. Before adding a second generator, review what the CMS already produces. WordPress SEO plugins update the sitemap automatically but can include attachment pages or tags unless switched off; on static sites the file must be regenerated whenever pages change.

Step by step:

• Start from the approved page list for the restored site.
• Remove pages that should not be indexed.
• Confirm each URL returns 200 at its final address and canonicalizes to itself.
• Generate the file with the platform’s SEO plugin, or as a static file for an HTML site.
• Reference it in robots.txt and submit it in Search Console once.
• Review the sitemap report and the page indexing report together after processing.
• Once a month, compare the sitemap with a crawl and remove anything that redirects or errors.

Record submission, processing and indexing as three separate statuses. A sitemap marked processed does not mean every listed page is indexed, and a sitemap does not replace internal links.

Multilingual sites: build language families before touching hreflang

Recover the right page in each language rather than duplicating one recovered page into several language folders. Preserve surviving localized URLs, confirm which translations actually exist, and connect only verified equivalents. A missing translation stays a documented gap until the owner supplies or approves new content.

Inventory the original paths, subdomains and domains, recording each page’s actual language as well as its URL pattern; a language folder is evidence about structure, not proof its contents were translated. Group pages into one family per equivalent subject, not per menu position. A worksheet with one row per family and one column per language, recording the URL, the source date and a status of recovered, translated fresh, waiting or not offered, shows at a glance which languages are complete. Have someone competent in each language review names, dates, contact routes and service claims, because a restored translation should not repeat a withdrawn offer just because its capture is newer.

Then connect verified equivalents. Each language version lists itself and its alternates with full URLs, in both directions. HTML tags, HTTP headers and sitemap annotations are equivalent methods; use one. A region code alone does not identify a language, and an x-default can point to a genuine selector page but does not replace the language pages. Annotate the approved restored address, never a Wayback replay URL, and do not automatically make every English page the alternate of a foreign-language homepage.

Review canonicals separately: a canonical names the preferred version of duplicate content, hreflang names localized alternatives, and pointing every translation’s canonical at the English homepage mixes those jobs. Test the switcher from several pages on desktop and mobile. It should land on the matching page, not the other language’s homepage, and where no equivalent exists the interface should say so.

Static HTML packages: deployment and ZIP QA

A ZIP that opens proves only that the package can be opened. Accept a recovered HTML site by checking the delivered files against the agreed page inventory and testing them at the intended deployment path, ideally on staging that matches the final server.

Ask for a delivery manifest: the pages included, their intended public addresses, the files that supply them, and the shared stylesheets, images, fonts, scripts and downloads, with each item labeled as recovered, recreated or owner-supplied. Check it against scope before looking at appearance. Confirm whether the package expects the domain root or a subdirectory and which folder is the deployment root; a package with a top-level delivery/ folder may intend that folder’s contents for the web root, and uploading the folder itself would put every page under /delivery/. Test in an HTTP preview rather than by double-clicking files, because scripts and included resources can fail under file://.

Sample by template and risk: the homepage, a long article, a nested page, an image-heavy page and every distinct layout. Then test journeys: open a deep page directly, reach it from the homepage, follow a contextual link, open an approved download, and use the logo to return home.

The problems that recur in recovered HTML packages:

• Leftover archive code: toolbar scripts, banners or links to web.archive.org.
• Missing CSS background images, web fonts or icons loaded from another domain.
• Case-sensitive filenames that work locally and break on a Linux server.
• Forms with no destination, and absolute paths that only work on the original domain.
• Outdated phone numbers, addresses or opening hours copied from the capture.

Separate static appearance from operational scope. A contact form, a login screen or a cart button can survive as markup while the original application does not. Ask the supplier to state which functions are display-only, newly rebuilt, configured but unverified, or tested with evidence. A success message proves only that the interface showed one; distinguish it from a submission recorded at the destination and a message that actually arrived, and agree the recipient and test data before any live test. Keep an untouched copy of the delivered package outside the hosting account. Accepting the ZIP does not authorize deployment.

Measure search recovery with three separate records

Keep three records: whether important URLs can be crawled and indexed, whether relevant searches produce visibility and visits, and whether those visits lead to genuine enquiries. A restored page, a submitted sitemap or a single search result does not prove that rankings or demand have recovered, and no reliable universal timeline exists.

Start with a chronology: the last known working date, the outage period, the date essential pages returned, and later content or technical changes, so the recovery can be separated from advertising, seasonality and tracking changes. Retain the original URL list; if addresses changed, map old to new before comparing page-level reports, or a move will look like a loss at one URL and unrelated growth at another. If historical analytics are unavailable, start a dated post-restoration baseline and say so.

First checkpoint, technical availability: inspect important pages with Search Console’s URL Inspection, recording whether you looked at the indexed view or a live test. A passing live test does not guarantee indexing, and an indexing request is only a request. Second checkpoint, visibility: in the Performance report, use the same page, query, country and device filters across equal-length periods and separate brand from non-brand queries, because a site-name query can recover while service discovery stays weak. Average position is an aggregate and the newest data can be preliminary. Save the filters and export date so the comparison can be reproduced. Third checkpoint, outcomes: confirm the route from an organic landing page to a real enquiry works, and keep an aggregate lead register by date range and landing-page group without customer messages or personal data. Search Console describes exposure, analytics describes measured activity and the business record describes received contacts; reconcile the definitions before diagnosing a fault from mismatched totals.

For AI answer engines, keep reproducible observations (platform, prompt, date, response, cited destination) and repeat a small fixed set of prompts at intervals rather than changing the questions until a flattering answer appears. At each checkpoint, write the figures into a short review record with one line of interpretation. If impressions fell to almost nothing rather than declining gradually, look for an indexing or crawling cause before blaming the restoration itself.

Handover: what the owner should receive

End with a bounded decision: accept the agreed scope as verified, accept with recorded exceptions, or withhold acceptance pending specified corrections. Before deciding, have the owner perform one representative editing task from the agreed package, such as updating a paragraph or replacing an image, using the delivered method. A static HTML delivery, an HTML-based Simple WordPress delivery and a visually editable Elementor build offer different editing, so do not accept a visual-editing promise because a WordPress login exists. Known gaps can remain only as clearly understood exceptions, never presented as recovered components.

The owner should receive:

• Access details for hosting, the CMS and any services, transferred to the owner’s own accounts.
• A coverage list showing which pages were restored, rebuilt or left out, with reasons.
• A URL record of old addresses, new addresses and redirects.
• A backup of the final site stored outside the hosting account.
• Editing notes for common tasks.
• A list of every connected service, its purpose and its account owner.
• A list of known gaps and agreed follow-up work.

Agree who is responsible for updates, backups, renewals and security from day one, and if the restorer is not providing ongoing support, say so in writing. A brief check of forms, indexing and performance a few weeks after launch catches issues early, because hosting changes, plugin updates and expired third-party scripts can break parts of a site that passed QA on delivery day.

Frequently asked questions

Does visual similarity prove the restoration is complete?

No. It does not establish content coverage, working historical URLs, editing behavior or verified functions. Use the acceptance record.

Can a canonical tag replace a redirect?

Not reliably. A canonical is a hint to search engines; a redirect actually sends visitors and crawlers to the new address. Use a redirect when a page has moved.

How often should the sitemap be resubmitted?

Once is usually enough. Search engines recheck it regularly, so keeping it accurate matters more than resubmitting it.

How soon should traffic return?

There is no reliable universal answer. Review verified technical status, comparable search evidence and business outcomes over time, accounting for the length of the outage.