Begin with the site and content that already exist
An AI design becomes generic when the model receives a category label instead of the actual information architecture, content types, proof, brand rules, and conversion path. Inventory published pages, posts, taxonomies, navigation, language relationships, media, forms, redirects, legal surfaces, and analytics before drawing a new homepage.
Real content changes layout decisions. A bilingual technical case study, an editorial archive, a founder profile, and a project-qualification form do not behave like placeholder cards. The design must accommodate their actual length, hierarchy, and editing needs.
- Current page and post inventory
- Primary buyer questions and conversion actions
- Reusable content fields and translation relationships
- Evidence that must remain first-party
- Legacy URLs, redirects, and indexation risks
Use a static prototype for visual exploration
Static HTML is a fast medium for testing typography, colour, rhythm, section sequence, motion, and responsive composition. It is also disposable. That makes it useful for exploring a distinctive direction before production constraints dominate the conversation.
Approve the prototype at representative desktop, tablet, and mobile widths. Test long French labels, real article titles, navigation wrapping, reduced motion, keyboard focus, and loaded images. A prototype approved only at one desktop width is not an approved responsive system.
Translate tokens into theme.json v3
Move the stable design vocabulary into WordPress: palette, typography, local font files, spacing, layout widths, control radii, and element defaults. Registered presets make editor output and front-end output share one vocabulary. CSS should handle the effects and relationships that theme.json cannot express, not duplicate every token.
This boundary reduces drift. Editors can select approved values while the theme retains control over contrast, scale, and spacing. It also makes later redesign work a system change instead of a page-by-page repair.
Convert structure into native blocks
Map paragraphs, headings, lists, buttons, images, groups, columns, details, navigation, post content, and query results to core blocks. Use templates for page-level structure and patterns for reusable editorial sections. WordPress should remain able to edit the content without exposing a wall of opaque HTML.
In the TechnoConception implementation, ordinary photography, service cards, process steps, proof lists, and FAQs became native blocks. Custom markup remained only for labelled product evidence and specialized system diagrams whose semantics would otherwise be lost.
Preserve dynamic WordPress behaviour
A static prototype may hard-code recent posts, navigation, metadata, or content. The block theme must restore the content-management model: Query Loop for archives, Post Content for singular templates, Navigation or a controlled dynamic block for menus, and translated equivalents for language switching.
If changing a post title requires editing a homepage HTML fragment, the conversion is incomplete. If changing a service image requires a developer to rewrite markup, the design is still functioning as a static host.
Add mechanical guardrails
Human review identifies the right boundary once; automated checks keep it from drifting. Search templates and parts for raw HTML blocks, validate theme.json version, require Post Content in singular templates, and maintain an exact count or allow-list for reviewed exceptions.
Run PHP lint, WordPress production QA, checksum verification, link and metadata checks, plus real-browser tests at desktop, mobile, and an awkward intermediate width. A failure near 675 pixels is just as real as a failure at 390 or 1440.
Deploy as a reversible release
Back up the database and current theme, validate the new source before maintenance mode, deploy with secure ownership, reseed or migrate content deterministically, flush rewrites and cache, then run production checks before reopening the site.
The useful result is an approved design that remains editable, testable, secure, and recoverable. For a broader comparison of implementation boundaries, read native WordPress blocks versus custom HTML and block themes versus page builders.
