Accept a recovered HTML website by checking the delivered files against the agreed page inventory and testing them at the intended deployment path. A ZIP opening successfully proves only that the package can be opened. It does not establish that every page, image, download or function works.
Ask for a delivery manifest
The manifest should identify the pages included, their intended public addresses and the delivered files supplying them. It should also list shared stylesheets, images, fonts, scripts and downloads. Keep unresolved items visible rather than omit them from the list.
Useful delivery labels distinguish an original recovered component from newly recreated work and an owner-supplied replacement. These labels let you review fidelity without treating every delivered byte as historical evidence.
Check the manifest against the agreed scope before reviewing appearance. A beautiful homepage cannot compensate for an omitted service page or missing legal document. If the package excludes a page, the acceptance notes need to say why and what the approved outcome is.
Confirm where the package is intended to run
Ask whether the package expects the domain root or a subdirectory. Identify which folder is the deployment root and which file serves each entry page. Do not infer this solely from a ZIP filename.
For example, a package with a top-level delivery/ folder may intend the contents of that folder for the web root. Uploading the extra folder itself could put pages below /delivery/ instead. This is a hypothetical packaging example, not deployment advice for a particular server. The handover should resolve the intended structure before any upload.
Use an isolated HTTP preview that reflects that agreed structure. MDN explains that some examples do not run when opened as local files: asynchronous requests or included resources can encounter browser security or CORS restrictions under file://. A local HTTP preview tests those dependencies more realistically than double-clicking the HTML file, although it still does not reproduce the production host exactly. Do not modify production infrastructure merely to make a preview pass.
Sample by template and risk
A page-by-page inventory check establishes scope, while representative visual checks establish how different layouts behave. Include the homepage, a long article, a nested page, an image-heavy page and any distinct template. Add high-value pages even if they share a template.
Review at narrow and wide widths. Check readable text, navigation access, image proportions, buttons, focus visibility and content that extends beyond the viewport. Compare with dated references where available; label improvements or replacements rather than claim they were present historically.
Inspect actual resource requests when something is missing. The Chrome Network panel can help identify requests and responses. Do not approve a stylesheet or image only because its filename appears in the manifest.
Test journeys, not just isolated pages
- Open an original deep-page address directly.
- Navigate there from the homepage and from another deep page.
- Follow a contextual link to the intended supporting page.
- Open an approved download and check its content.
- Use the logo and primary navigation to return to a known destination.
- Review intentional external links separately from local resources.
Record the starting page, final destination and observed result for each failure. A redirect to an unrelated page or an error message returned with a successful status is not a passing navigation result.
Separate static appearance from operational scope
A static package can contain a contact form’s visible fields without its processing service. Likewise, a login screen, search box or cart button can survive as public markup while its original application does not.
The Internet Archive describes limits where interactions depend on the originating host. Ask the supplier to state which functions are display-only, newly rebuilt, configured but unverified, or tested with specific evidence.
Any live submission, payment or account test requires explicit agreement. Do not treat a success message as proof of email delivery or authorize real transactions merely to finish ZIP acceptance.
Approve the handover with exceptions visible
Keep an untouched delivered package, the manifest, the test notes and the accepted exception list. State who handles deployment and who handles ongoing forms, accounts and integrations. A checksum can help identify a particular package version, but it does not prove that the contents meet the restoration scope.
An effective acceptance statement is specific: named pages verified, named tests completed and named gaps accepted or awaiting correction. Avoid “fully restored” when essential functions remain untested.
The HTML restoration package should be chosen against this static-delivery scope. If the owner needs editable content or new application behavior, agree that requirement separately rather than expect it to appear inside an HTML ZIP.
Does accepting the ZIP authorize deployment?
Not automatically. Content acceptance, deployment authorization and operational verification are different checkpoints. Agree each responsibility and preserve a rollback reference before replacing a live site.
