How do you make an AI-built website not look AI-built?
Most AI-built websites look AI-built because they repeat the same measurable patterns: em dashes in copy, filler verbs, placeholder names and stock purple gradients. The fix is not to edit the finished page. It is to apply a rulebook at build time and follow a real design language with exact palettes and type, so the tells never appear.
What tells do readers learn to spot?
Readers do not need to inspect the code. They notice repeated surface patterns and begin to associate them with generated pages. The most common tells are measurable, not vague impressions.
Each tell is a count or a string, which means a rulebook can check for it before a page is published. An opinion such as 'make it look premium' cannot catch a placeholder name or a stock gradient.
| Tell | Why it reads as AI | Build-time fix |
|---|---|---|
| Em dashes in copy | Common model output | Flag them for plain punctuation |
| Filler verbs like 'unlock' | Generic marketing tone | Replace with concrete verbs |
| Placeholder names | No real project data | Check names against project data |
| Stock purple gradients | Default AI aesthetic | Apply exact palette from design language |
| Symmetrical, generic layout | No specific decisions | Follow a chosen design look with type and spacing |
Why does fixing after the fact fail?
Editing a generated page by hand can remove one tell from one page, but the next build reintroduces the same habits. You end up maintaining a style guide in your head while the generator keeps producing the default patterns.
A build tool such as GROX Code can apply a rulebook during generation, before the page exists. That is the difference between correcting output and changing the process that creates it.
What changes when you follow a real design language?
Saying 'make it look premium' gives an AI no decision to follow. A design language gives exact decisions: which palette, which type, which spacing, which layout patterns. The result is consistent because the input is specific.
When a project has its own brand, that can be written as a DESIGN.md file readable by any AI tool. If it does not, a set of brand-inspired looks with exact palettes and type can provide a starting point. Neither is the same as asking for a vague mood.
- Exact palette stops rather than 'blue'
- One type scale rather than 'modern fonts'
- Named components rather than 'clean sections'
- Real copy decisions rather than filler verbs
What does a rulebook check that an opinion cannot?
A rulebook checks the measurable tells of AI-generated design as counted facts, not as a model's taste. It can reject a page for an em dash, a placeholder name or a stock gradient without asking whether the page feels right.
- Measurable tell
- A pattern that can be counted in source or copy, including em dashes, filler verbs, placeholder names and preset gradients.
- Design language
- A defined set of palette, type and layout decisions applied across a project.
- Build-time rulebook
- Checks that run while a page is generated, so the tells are removed before publication.
- Opinion check
- A subjective judgement about quality or premium feel, which changes between reviewers and misses specific faults.
When is a simpler tool the better choice?
If you are publishing a single static page and will not generate more, hand-writing the HTML and copy may be faster than setting up build-time checks. A simpler tool is also the right call when you only need small copy changes on an existing site.
The rulebook approach earns its keep when you build repeatedly, when several people or agents produce pages, or when consistency across many pages matters more than one-off speed.
Common questions
Do em dashes really make a website look AI-built?
One em dash is not proof, but a pattern of them is. Generated copy tends to favour the em dash where a full stop, comma or semicolon would read more naturally. Readers notice the rhythm before they can name it. Removing them at build time removes one of the most consistent tells.
Can I just rewrite the copy after generating?
You can, but the fix does not last. Each new page or rebuild reintroduces the same filler verbs and punctuation habits unless the build process itself checks for them. Editing by hand turns into a repeated manual step, which is exactly what automation should remove.
What if I need a brand that is not one of the preset looks?
Write the project's own brand as a DESIGN.md file. It can include the exact palette, type choices and rules that any AI tool can read. That works whether the starting point is a preset look or a completely custom identity, and it keeps future builds aligned with the same decisions.
Is a rulebook only for AI-built pages?
No. A rulebook is useful for any team that produces many pages, human or automated. The measured checks are the same: punctuation habits, placeholder names, vague verbs and off-brand colours. Applying them before publication catches mistakes earlier, whether the author is a person, a model or both.
See how GROX Code applies a build-time rulebook and exact design language at grox.life.