A website converter can finish successfully while producing an incomplete public site. It may capture the homepage but miss an archive, preserve a menu that no longer opens, or leave image requests pointing at the old server. Validation therefore starts with a different question from conversion: can this exact output serve the intended website without hidden dependencies, missing content, or broken visitor journeys?

Treat the output folder as a release candidate. Keep it unchanged while you check it, record findings, then generate a new candidate when corrections are needed. That prevents an approved screenshot from referring to a different version of the files you eventually publish. The website converter guide explains what conversion can produce; the process below establishes what you can reasonably conclude from inspecting the result.

Define acceptance before counting errors

Write a short acceptance statement for the website. It should identify the pages that must exist, the visitor actions that must work, the URL structure, and the hosting assumptions. Specify whether the site is entirely self-contained or intentionally uses external media and services. Without those expectations, a validator can report technical details while the team still disagrees about whether the website meets its purpose.

Separate release-blocking defects from improvements. A missing contact page, inaccessible navigation, incorrect destination, or absent article is a clear blocker when the scope requires it. A minor spacing preference may be suitable for a later revision. Assign an owner and a reproducible example to each issue. This keeps the review focused on observable results and makes repeated validation proportional to the changes actually made.

Compare the output with a page manifest

Use the approved source inventory as the expected page list. For each destination, record the generated file, canonical URL, title, and status when served. Include documents, archive pagination, and pages reached by direct links. A count alone can hide duplication: ten generated files are not evidence that the intended ten pages are present. Compare identities and content, not just totals.

Look for unexpectedly empty or repetitive pages. An exporter may save a login screen, a generic error page, or the same fallback document under several filenames. Sample the beginning and end of long articles, inspect distinctive headings, and compare meaningful text with the source. Review intentional removals separately. They should match the migration plan instead of appearing as unexplained gaps in a crawler report.

Serve the files the way the host will

Open the candidate through an HTTP static server, not only by double-clicking an HTML file. The server should support the directory index behavior expected in production. Enter a nested URL directly, reload it, follow a link to a sibling page, and request a missing path. If the project promises clean directory URLs, confirm that a corresponding index document exists rather than depending on an application router.

Check path capitalization on the actual hosting environment and inspect trailing-slash behavior. Verify that links resolve correctly from deeply nested articles. A path that works from the homepage may point somewhere else from an archive if it was written incorrectly. Use the same public-root assumption throughout the site. The static hosting guide helps identify host behavior that belongs in the acceptance statement.

Extract links and resource references from the HTML and stylesheets. Check internal pages, fragment identifiers, images, responsive image candidates, fonts, scripts, background images, icons, and downloadable documents. Verify that fragment links identify real elements on the destination page. Do not stop at a successful response code: open files of each important type and confirm that their contents match the expected resource.

Scan for the old domain, staging hostname, local filesystem paths, and references to the source application's administrative endpoints. Each remaining occurrence needs an explanation. An intentional attribution can be valid; a stylesheet loaded from an old editing server can make the new site fragile. Check for protocol-relative URLs and mixed schemes as well. Maintain an explicit list of external dependencies so future maintainers can see what the public files require.

Check that the captured view is the public view

Inspect whether the conversion ran with the intended visitor permissions. A capture made from an authenticated editorial session can differ from the public page. Look for draft text, administrative controls, personalized greetings, and private download references. Compare sensitive or unusual pages with a logged-out public view of the approved source. Also inspect comments and embedded data in the exported HTML, since content can be present without being visible on screen. Correct the source or export settings and regenerate the affected output instead of relying only on visual concealment.

Use markup checking as one layer

Run generated HTML through a conformance checker and investigate messages that indicate structural mistakes. The Nu Html Checker documentation explains that checking helps catch unintended markup problems and is not a pass-or-fail certification mechanism. That distinction matters: a clean report does not demonstrate accurate content, working navigation, or complete accessibility. Keep the report alongside other evidence rather than treating it as the whole decision.

Review repeated errors at the template level. A malformed navigation component can affect every page, so correcting the source template is usually more maintainable than patching exported files individually. Rebuild and recheck a representative sample before scanning the full output again. Preserve any deliberate exceptions with a brief explanation. An unexplained suppressed warning is difficult for another maintainer to assess later.

Exercise the interface with real actions

Use a narrow viewport, a wider desktop viewport, and keyboard-only navigation. Open and close the mobile menu, move through interactive elements, activate links, and confirm that focus remains visible. Check the sticky header near anchored headings and when the page is zoomed. Inspect long titles, code blocks, tables, and unusually wide images; these reveal layout failures that short demonstration content can conceal.

Turn JavaScript off for a separate content review. Essential reading and ordinary links should remain usable when that is part of the project's requirements. Then enable it and inspect the browser console and network requests while exercising each enhanced control. A menu animation that works is not evidence that a download button or tab interface works. Write tests around the actual visitor actions, including the destination reached and the visible result.

Verify page identity and discovery files

Check unique titles and descriptions, one clear primary heading, sensible heading order, canonical URLs, and social preview assets. Confirm that structured data matches visible content and uses the correct domain. Inspect article dates against the editorial record. Keep unsupported claims out of structured data just as you would keep them out of the page itself. Machine-readable markup should describe the published website accurately.

Parse the sitemap and feed, then compare their entries with the approved canonical page list. Open every referenced image and page path locally or on staging. Confirm that robots directives reflect the intended public launch. A staging restriction accidentally included in the final release can undermine discovery even when the page looks finished. Validate the final generated files, because hand-checking a template does not prove that every output entry is correct.

Inspect the package and its dependencies

Extract the final archive into an empty directory and repeat a small set of essential checks there. Confirm that the public entry document sits at the expected root and that required assets are included. Keep source backups, credentials, private notes, and unrelated dependency folders outside the public package. If the site is advertised as ready to upload, the extracted output should not require an undocumented build before it can be served.

Disconnect or block the former origin during a controlled review where practical. Observe which requests fail and whether the expected static experience survives. This is a useful way to expose accidental dependencies, but it should complement the explicit reference scan. For projects leaving WordPress, the WordPress conversion guide and migration checklist connect these findings to the source-content and editorial decisions.

Conclusion: approve a specific, recoverable release

Finish with a concise validation record: the candidate identifier, expected scope, completed checks, unresolved limitations, and approving owner. Keep the approved package and a recovery copy. Validation is successful when the evidence supports the intended visitor experience and the files being published are the same files that were inspected. That provides a much stronger basis for launch than a converter's completion message or a single attractive screenshot.