The preview is not the product
An AI agent can produce a page that looks finished before the underlying decisions are safe. The navigation works at one viewport. The copy fits the current card. The build command succeeds. None of that proves the site can be owned, maintained, indexed, or launched without avoidable risk.
Production readiness is a property of the whole system. It includes the source, content model, design rules, output, hosting, and operating instructions. A polished page is one visible artifact inside that system.
This distinction matters because AI compresses implementation time. It does not compress responsibility. Faster output gives teams less time to notice an architectural mistake before it spreads across every route.
Seven layers have to agree
The brief
The repository needs a precise job to do. Who is the site for? What action should a visitor take? Which claims are approved? Which routes are required? What must not be invented?
Without those constraints, the agent fills gaps with plausible choices. Plausible is dangerous in production because it can look intentional while being commercially or factually wrong.
The information architecture
Every public route should have a purpose, a place in the hierarchy, and an inbound path. Similar search intents need consolidation. Utility and draft states need an explicit index policy. The 404 route and redirect behavior belong here too.
Architecture is not a sitemap generated after the build. It is the logic that decides what deserves a URL.
The design system
Tokens and primitives turn art direction into reusable constraints. They define color roles, typography, spacing, containers, borders, interaction states, and responsive behavior. When the agent needs a new editorial pattern, it should extend those rules rather than opening a parallel visual vocabulary.
That is why visual inconsistency cannot be fixed by asking for “more polish.” The agency production workflow shows how design and engineering can give the agent a smaller, clearer decision space.
The implementation
The code should make good defaults cheap. Repeated metadata belongs in helpers. Repeated layout belongs in components. Content fields need validation. Client JavaScript should appear only where interaction requires it. Dependencies should have a reason to exist.
Static output is often a strong default for product, editorial, and marketing sites. It makes the primary document easy to inspect and cheap to distribute. Static architecture does not excuse weak content or broken links; it simply removes unnecessary runtime uncertainty.
The release evidence
“The agent says it is done” is not evidence. A release should produce observable results:
- type and framework checks pass;
- the production build completes;
- content validation reports no critical errors;
- internal routes resolve;
- index directives, canonicals, and sitemap entries agree;
- representative pages work across viewport sizes;
- keyboard focus and heading structure remain coherent;
- production headers and status codes match the configuration.
Some checks are automated. Others require human judgment. Both should be named before launch.
The deployment
The path from repository to production needs a single source of truth. Teams should know which branch deploys, which account owns the project, where environment values live, and how a rollback works. DNS changes should be narrow and deliberate. Email records are not part of a routine website deploy.
Deployment convenience is not the same as operational clarity. A command that publishes from one laptop can work while leaving the next maintainer with no reproducible process.
The handoff
Production work has an owner after launch. The repository should explain how to install, build, validate, update content, and deploy. Known constraints should be written down. Domain, hosting, analytics, payment, and source ownership need to be explicit.
An agent can help prepare that material. The accountable parties still need to approve it.
A useful production test
Ask whether a competent person who did not participate in the build could make a safe content change six months from now.
Could they find the right file? Would the schema catch a missing description? Would the layout preserve the design? Would the check identify a broken related link? Could they build locally and understand which action publishes to production?
If the answer depends on recovering an old chat transcript, the website is not well handed off. Conversation is working context. The repository is durable context.
The AGENTS.md website-development guide explains how to place operational rules where coding agents can discover them on future sessions.
Common signs of a generated prototype
A site may need more work if it has several of these symptoms:
| Symptom | Likely missing system |
|---|---|
| Every section uses a slightly different container | Layout tokens and section primitives |
| The home page has metadata but articles do not | Shared SEO contract |
| Important copy appears only after hydration | Rendering policy |
| Cards break when titles get longer | Real-content stress testing |
| New routes are absent from navigation | Route and internal-link model |
| The 404 page returns the wrong behavior | Hosting verification |
| No one knows which account deploys | Operational ownership |
| “Updated” dates change on every build | Editorial freshness policy |
These are not cosmetic defects. Each one shows that an important decision is implicit.
Inspect a generated site in dependency order
Start with the repository, not the browser. Identify the package manager, framework version, output mode, route sources, content model, global layout, deployment files, and production commands. Look for duplicated components or page-level metadata that should have a shared owner. Check whether the lockfile and documented runtime agree.
Then build the site. The built directory is the contract between Astro and the host. Inspect a representative HTML document directly. Confirm that the main content, navigation, canonical, description, robots directive, and structured data are present. Count client scripts by route and identify what each one does. Inspect image dimensions and font files rather than assuming an optimization integration handled them.
Only then move to a browser and production host. Test narrow and wide layouts, keyboard order, slow loading, missing routes, redirects, headers, and the purchase path. This order helps distinguish a source problem from a build problem and an edge-configuration problem.
A useful inspection record names the observation and its owner:
| Observation | System owner | Verification |
|---|---|---|
| Article has no canonical | Shared metadata layout | Built HTML contains one correct canonical |
| Mobile card overflows | Card primitive or content constraint | Long real title fits at narrow width |
| Missing route returns home | Static-host 404 configuration | Unknown URL returns the 404 document and status |
| Button label is ambiguous | Content and component usage | Link purpose is clear outside visual context |
| Deployment requires one laptop | Repository and hosting workflow | A documented authenticated runner can publish |
Do not mix every defect into one redesign task. Repair the highest shared owner first, rebuild, and see which symptoms remain.
A small-site failure can still be systemic
Imagine a five-page consultant site generated from a good-looking reference. The home page has a title and description because they were written directly in its template. The service pages copy that template but retain the home canonical. A client-side navigation component contains the only links to those services. The production host serves the home document for unknown paths with a 200 response.
Every individual choice can pass a casual review. Together they make the site difficult to crawl, create duplicate signals, and hide real errors. Adding another SEO plugin will not solve it.
The repair starts by moving metadata into one typed layout, rendering navigation as ordinary links, defining the static 404 behavior, and adding output checks for one canonical and one H1 per indexable route. The site is still five pages. The architecture now makes the sixth page safer.
Prevention should follow the cost of failure
Not every rule belongs in CI. Use hard failures for conditions a machine can judge reliably: invalid schema fields, missing required metadata, duplicate canonical routes, broken internal references, type errors, and a failed production build. Use warnings for signals that require context, such as an unusually short article or a page with few related links.
Reserve human approval for decisions with business, legal, visual, or operational consequences. A validator cannot confirm that a testimonial is authorized, a comparison is fair, or the domain change is acceptable. It can confirm that an author field exists; it cannot prove the author is real.
This layered model avoids two bad extremes. One is a build that passes almost anything. The other is a brittle wall of arbitrary scores that teaches contributors to satisfy the checker instead of improving the site.
Production changes need the same discipline as launch
The system is most likely to drift after the initial release. A campaign page bypasses the content model. A new integration adds global JavaScript. Someone copies a card because the documented variant was hard to find. A temporary redirect becomes permanent by neglect.
Treat meaningful changes as small releases. Identify affected routes, update the durable rule when needed, run the same checks, inspect the production diff, and verify the live result. Freshness dates should change only when the article materially changes. Sitemap and internal links should be updated when a route moves, not at the next audit.
Maintenance is where repository context earns its keep. The original agent session is gone; the production standard remains legible.
What AI is good at inside a production system
Agents are effective at tracing patterns through a repository, applying a component change across routes, generating typed content entries, running checks, and explaining failures. They can compare built files against conventions much faster than a person inspecting every line by hand.
They are less dependable when the task asks them to invent the standards while simultaneously implementing the site. The output may be internally inconsistent because each local choice was reasonable in isolation.
So divide the work. Humans set the commercial facts, creative direction, risk boundaries, and release authority. The repository carries stable rules. The agent implements, tests, and reports within those boundaries.
Production-ready is not “never changes”
A strong launch is designed to change. Tool documentation moves. Offers develop. Search architecture expands. New contributors arrive. The system should make those changes legible and testable without freezing the site in its first version.
That is the bar. Not perfection. Not infinite process. A production-ready AI website is one where the critical decisions are owned, the output is verified, and the next change does not require starting over.