When a downloaded Wayback website has broken links, compare the address requested by the browser with the file or route actually delivered. A navigation error can come from a wrong relative path, a changed deployment root, a filename mismatch or a page that was never recovered. Those problems need different fixes.
Reproduce one broken journey precisely
Start from the page containing the link. Record that page’s address, the link’s source value, the resolved destination and what happens when it opens. Test the same journey in the intended hosted test environment as well as in any local preview.
A homepage opening from a folder does not prove its deeper navigation will work after deployment. File previews and HTTP hosting do not share every loading rule. MDN notes that local file-origin behavior can block some resources and varies with the environment. Do not disable security to make a preview pass.
A deep-page path example
This synthetic example illustrates address resolution, not an actual restored website. A page at https://example.com/guides/check.html contains a link to contact.html. Without an overriding base address, that relative reference points within /guides/, not automatically to the website root.
If the delivered contact page is /contact.html, the mismatch explains why the link can fail even though the target file exists. A developer can correct the reference in a working copy after confirming the intended destination. If the intended contact page was instead /guides/contact.html and it was not recovered, changing the path would conceal a missing-page problem rather than solve it.
Check the document’s base element as well. The HTML base reference explains how a base address changes relative URL resolution. A leftover archive or old-host base can affect many links at once.
Match the path to a real target
Inspect the delivered file tree and any documented routing behavior. Compare the requested path with the actual filename, extension, letter case and directory nesting. Do not assume a host treats About.html and about.html as interchangeable.
A directory address such as /help/ and a file address such as /help.html may need different hosting behavior. The delivery should state what it expects. A ZIP that contains an index file in a folder does not, by itself, establish the intended server’s routing configuration.
Separate three findings:
- Existing target, wrong reference: correct the link after verifying its intended destination.
- Existing target, wrong deployment assumption: review the documented root or routing requirements with the deployer.
- No delivered target: return to source recovery or record the unresolved page.
An error response alone cannot tell you which finding applies. Check the target and the resolved request together.
Do not hide missing pages behind redirects
A redirect is not a substitute for recovering the page a reader expected. Sending every broken link to the homepage removes the visible error but often loses the user’s purpose. First determine the original content and whether an appropriate destination exists.
If a public address genuinely needs a redirect, record a one-to-one proposal and get the owner’s approval. Avoid changing established URLs merely to match a downloader’s filenames. Preserve the original URL map and let the implementation conform to that plan where practical.
Archive-wrapper cleanup is another separate task. If the failure is an embedded replay address, identify the original destination and a verified replacement rather than treating it as a generic nesting error.
Retest from different starting pages
A root-level menu can work while the same link fails on a page several directories deep. After a correction, test from the original failing page and another depth. Include a logo link, navigation item, contextual article link, image and download.
Use browser network inspection to check the requested destination and returned content. Recheck the final address after redirects, not only the first status. Keep screenshots or notes for the actual result where they help explain the defect.
The handover should identify the path rule corrected, affected files and unresolved targets. For missing captured content rather than a path mistake, the restoration guide explains the wider recovery process. A well-diagnosed path fix should not be advertised as recovering material that never arrived.
Can I rename all files to solve path errors?
Not safely as a blanket rule. Renaming can break other references or change established public URLs. Correct a verified mismatch with a reversible record, then test every affected route.
