An AI website builder can produce a convincing preview long before it produces a dependable static release. The preview may rely on a development server, remote styling scripts, invented content, or controls that have no implementation. Before publishing to IPFS, evaluate the exported files as an ordinary website and as a public release artifact.
This checklist is designed for developers and publishers who use generated code or content as a starting point. It does not assume a particular AI product, promise automated correctness, or equate visual polish with readiness. The central question is simple: can you inspect, rebuild, test, and operate the exact folder you are about to distribute?
Write an output contract first
Describe the artifact you require before asking for a design. Specify static HTML, a compiled stylesheet, lightweight scripts, real page directories, included images, and no hidden backend requirement. State which features are intentionally absent, such as account systems, contact forms, payments, or live search.
Give the builder a route inventory and require every navigation item to resolve to a completed destination. Ask for a content inventory too: titles, descriptions, article excerpts, publication dates, and image filenames. These requirements turn a vague instruction to make a website into something you can verify.
Our AI IPFS website builder overview outlines the review stages. Treat the builder as a contributor to that process, not as the final authority on whether its own output is ready.
Inspect the export, not only the preview
Open the generated directory and identify what it contains. Look for source files that still require a build, packages that only work in development, and references to services that are not included in the delivery. A screenshot cannot answer these questions.
Run the site through a local static HTTP server with the development server stopped. Open a nested page directly and reload it. If the website only works when launched through the builder's special preview environment, the export has not yet demonstrated the portability you need.
Check the browser's network panel for unexpected requests. A site that imports its styling engine or images from temporary preview URLs may fail after those services change or disappear. Decide which external dependencies are deliberate and remove the rest.
Review generated instructions as untrusted input
AI-assisted workflows often read templates, repository files, documents, and web content. Those materials can contain text that attempts to redirect the assistant or automation. The OWASP prompt-injection guidance describes this risk: supplied content can try to influence an application's instructions rather than merely serve as data.
For a publishing workflow, keep credentials and production deployment authority outside the generation step. Do not allow a template comment or fetched document to authorize changing DNS, uploading private files, or running arbitrary commands. Require review at the boundary between generated output and privileged actions.
This is a workflow-control problem, not a reason to assume every generated page is malicious. A narrow, inspectable process makes both accidental mistakes and deliberate redirection easier to contain.
Check content for invented claims
Read the homepage as though you were a visitor evaluating the organization. Remove unsupported customer counts, testimonials, partnership logos, certifications, benchmark results, and service promises. A polished template can make invented credibility look ordinary, which is exactly why it needs explicit review.
Check whether the copy describes an actual product or merely the site's educational topic. A guide to IPFS hosting should not accidentally claim to operate a hosting network. A page about AI builders should not present a working generator when the site only offers documentation.
Review technical claims against primary sources and distinguish facts from recommendations. Keep examples clearly labeled as examples. Do not let a request for search optimization turn into repetitive keywords or assertions that have no supporting evidence.
Verify the site is really static
Search the export for form handlers, server-only routes, database connections, and environment variables. Identify any feature that expects a runtime application service. Then either implement an appropriate external architecture deliberately or remove the feature from the static site.
A contact page can use a visible email address and a mail link without pretending that a form submits somewhere. A guide library can use category links without a search input that has no index. A documentation site can explain wallets without placing a nonfunctional connect button in its header.
Our IPFS static website guide describes the difference between public files and backend responsibilities. Use that boundary to evaluate every generated interaction.
Test routes and resource paths
Verify that every intended page has a physical entry document. Clean public URLs should correspond to real directories rather than depend on a development server's catch-all behavior. Crawl internal links and inspect any path that points to a missing file or an HTML extension where your route policy excludes it.
Check image sources, CSS background images, script imports, and links assembled in JavaScript. A builder may produce correct relative navigation but leave a root-relative resource path that escapes the release under a gateway prefix.
Test the homepage, a topic page, an article, and an archive directly. This small set covers different path depths and template types. Expand the test to every route before release rather than assuming one successful page proves the whole site works.
Review accessibility as behavior
Use the keyboard to open the menu, follow links, and operate expandable sections. Confirm that focus is visible and that a sticky header does not cover an anchored heading. Make sure controls communicate their expanded or collapsed state when appropriate.
Test narrow screens and zoom
Increase text size and inspect a narrow viewport. Check that long titles, code blocks, and email addresses wrap or scroll intentionally rather than widening the entire page. Test sufficient contrast in normal, hover, and focus states. A visually dramatic neon palette still needs readable text.
Read image alternative text for meaning. A decorative shape does not need a long description, while an instructional diagram should not be labeled merely image. Explicit image dimensions also help keep layouts stable while assets load.
Audit metadata independently from visible copy
Verify unique titles and descriptions, a single clear H1, canonical URLs, social preview images, and valid structured data. Check that the schema describes visible content rather than invented ratings, authors, or business details. Do not create an organization biography out of assumptions the user never supplied.
Compare article dates across the page, listing, structured data, and RSS feed. Use a consistent editorial policy and do not automatically turn every rebuild into a new modification date. Check that sitemap entries correspond to completed indexable pages.
For a longer editorial workflow, read the IPFS CMS publishing guide. The same validation principles apply whether the content came from a CMS, a text editor, or a generation tool.
Inspect the release for secrets and leftovers
Remove unused demo branding, sample companies, placeholder contact details, temporary images, and test credentials. Search both source and compiled files, because build tools can embed values in places that are easy to overlook.
Keep the deployment folder limited to public material. Do not include private notes, repository metadata, environment files, or dependency caches simply because the generated project arrived as a large ZIP. Preserve build instructions separately where needed, without making them a requirement for a reader to load the site.
Record what was tested and against which artifact. A passing check on yesterday's folder does not validate today's edited release.
Conclusion: make generation the beginning of verification
An AI-assisted site becomes publishable through review, testing, and a controlled release process. Define the output, inspect the actual export, verify claims, test accessibility and routes, and keep privileged deployment steps separate. Then publish and retain the approved folder as you would any other IPFS website. The useful promise is not that a builder can replace judgment. It is that a well-defined workflow can turn a draft into an artifact you understand.
