The Preview Looked Right. The Published Version Was Broken.

The build screen said the page was fine. Eight sections in the order they were requested, the date and the capacity correct, the navigation in place. Then it went live, and the hero image turned into a broken-image icon.

That is the small horror story from a Japanese review published on 30 October. MINATO, a writer at the note.com tech lab Planetdive, built three fictional sites with an AI site builder called Readdy over two days: a hackathon application page, a coffee subscription homepage from a template, and a booking page for a made-up osteopath clinic. All three were noindexed and labelled as test properties. The write-up is long, unusually specific, and mostly about the gap between what a generator shows you and what it actually ships.

The test, and who paid for it

The disclosure sits at the top of the article and it matters. Readdy supplied a free Pro plan, promised a year of the Starter plan for publishing the review, and pays affiliate commission on purchases made through the author's referral link or discount code. MINATO states this plainly and says the numbers come from their own screen.

Read the measurements as the work of a careful tester with a commercial relationship, not as an independent lab result. The numbers are still worth reading, because they are the kind you can go and reproduce on any generating tool in an afternoon.

The economics came out cheap. Twelve revisions and one initial generation cost 325 credits, roughly five percent of the 6,000 credits a month the Pro plan carries. A chat edit costs 25 credits whether you ask for one change or seven, which is why the author wrote prompts with Claude and sent batched instructions. The first page appeared in 2 minutes 12 seconds on the timer, though waiting for it felt closer to five.

Two bugs that only exist after you publish

Both failures appeared after the publish step and neither was visible in the preview.

The first one is the interesting one. The hackathon page's large desktop hero image stopped loading once published. In the editor it was fine. On the public URL the frame was empty. The image address had a mangled tail, and the suspected cause was punctuation: the image description contained "16:9", and the colon in that ratio appears to have interfered with how the publish step rewrites asset addresses. Removing the ratio from the description and rebuilding fixed all eight images on the page.

This is a category of bug that generated pipelines produce more often than hand-built ones, because the same string field gets used as both human-readable description and machine-parsed metadata. The caption becomes a filename. The alt text gets concatenated into a path. A colon, a slash, a percent sign, a quote mark, and the asset 404s. If you are generating images through an agent that writes its own filenames or alt text, "16:9" in a description is exactly the sort of thing that ends up in a URL.

The second failure was quieter. On the template-built coffee site, three of thirty images returned "Image source is unavailable" after publishing. They were product detail images, second or third in a gallery, not the ones on the top page, which is why a quick look at the homepage showed nothing wrong. The same gallery rendered fine in preview. Republishing about two hours later fixed it, and the author is honest that they cannot say whether the republish or the passage of time did it.

Two failures, two uncertain causes, one conclusion: the preview is a different pipeline from the publish target. Treat the public URL as the artifact and the editor as a sketch.

The color the model said it applied

The most reusable finding is smaller than either bug. Asked to switch a palette to blue, the assistant replied that it had applied the specified color codes. The author sampled the rendered page. The button background was #40BEFD instead of #1ABDF8. The text was #00060F instead of #091E2D. Close enough to look intentional, wrong enough to fail a brand check. A follow-up instruction landed the correct values.

The same piece has the counter-example that keeps it honest: one complaint about "almost black text" was the author's own fault, because the hex they had specified was in fact nearly black.

For anyone generating images rather than pages, this maps onto something familiar. A model will tell you it preserved your brand color, your palette, your reference. The claim is generated text about an image, produced by the same system that produced the image. Pick the eyedropper up and sample the exported file. On a chip, on a button, on a label, at 100 percent, not on a thumbnail and not on the canvas preview. Holding a palette steady across generations has its own discipline, covered in this guide to palette conditioning.

The review also caught simplified Chinese characters inside the assistant's Japanese replies, one character swapped for its mainland variant. Cosmetic, in a chat message, and still a signal about how much weight a language model's self-description can carry.

Published is not the same as readable

The part I did not expect from a site-builder review: what the published pages look like to anything that does not run JavaScript.

The static HTML for the hackathon page came back at 2,244 bytes with almost no body text, because the page assembles itself in the browser. Fetch it without executing scripts and you get a title, a description, and nothing to read. Fetch it with a rendering tool and the body appears, except the FAQ answers, which are collapsed, so only the questions come through.

Two files decide whether crawlers can work with a site, and a third is an emerging convention that nothing obliges an AI system to read: robots.txt, sitemap.xml, and llms.txt, which is still a proposed format. None of the three existed at first. Requesting robots.txt returned the homepage HTML. The noindex setting was applied, but through chat, because it has no switch in the settings screen.

The platform does have a fix: a Generate button under technical SEO. It ran for 212 seconds and 25 credits and produced a real robots.txt and a sitemap.xml listing ten pages, plus per-route metadata, canonical tags, social images and JSON-LD. PageSpeed's SEO score went from 58 to 69. What did not change: those tags are injected at runtime, so a script-less fetch still sees none of them, and noindex stayed on while the sitemap listed ten URLs. The sitemap is an invitation to discover pages. The noindex tag tells supported search engines not to index the pages it points at.

Any generated page or asset that is meant to be found has to survive a fetch with scripting off. If the text only exists after hydration, the page is a picture of a page.

Numbers that move without you

The speed measurements are the section to read twice.

The hackathon page scored 59 on mobile. The author spent 25 credits trimming unused icon fonts, consolidating typefaces, serving width-appropriate images and lazy-loading everything below the fold. It scored 58. The next day, with nothing changed, it scored 66. Largest contentful paint sat at 8.8 seconds in every single run, while the first paint dropped from roughly seven seconds to 3.2.

The coffee page scored 79, 80, 79 on mobile and 98, 99, 84 on desktop, while being heavier on every axis: 519 KiB of JavaScript against 333, 1,709 KiB of images against 771, plus a 3.5 MiB hero video. The reason is instructive. The largest element on the coffee page was the header logo text, not the video, which may be why the video's weight never counted against it. The page was not faster. The metric was measuring something else.

So measure, but measure twice: same day, same tool version, at least two runs, and check which element the score is actually timing.

Cheap edits change how you should work

Flat-rate editing is a workflow fact, not a pricing detail. When seven changes cost the same as one, you batch. The author did, and the visual-polish rounds alone (seven of the twelve revisions) consumed 175 credits, more than half the total.

Batching has a cost that shows up later: you stop being able to attribute effects. The same thing happened with the SEO button, which rewrote robots, sitemap, metadata, canonical, social images and structured data in one pass. The score moved. Nobody can say which change moved it.

Batch when the goal is speed. Isolate when the goal is learning why something works. Most teams batch everything and then wonder why their pipeline is a pile of superstitions.

The ten-minute check

The routine the review arrives at is short and it costs nothing but attention. Open the published URL, not the preview, on a phone as well as a desktop. Load every image on the page from top to bottom rather than scanning the fold. Submit each form once with dummy values and confirm it appears where the operator will actually look, which in one case meant an English notification email on a Japanese site, and in another meant a booking that reached the inbox and the calendar but never appeared in the dashboard.

For images specifically, add four steps to that list. Sample the exported file for the color you asked for. Open the actual file at 100 percent instead of trusting a canvas preview. Check that alt text and captions did not leak into filenames. And confirm the phrase "16:9" is nowhere near a field that becomes a URL.

The tools are getting good enough that the failure mode has shifted. It is rarely "the output is obviously wrong." It is "the output looks right in the one place you checked."