A WordPress conversion should not be judged only by its first screenshot. This test measures whether a supported source reaches a reviewable draft, what still needs repair, and whether another person can make the first real content change.
The methodology is public now. Case results will be added only after each source, screen recording, timing log, editing check, and limitations note can be published. This page does not present planned tests as completed evidence.
Disclosure and scope
This is a Tahmir-run benchmark designed and published by Awais, the founder of Tahmir AI. It is product research, not an independent laboratory study or third-party review. The protocol is public so reviewers can challenge it, repeat it with other products, or use the same files and acceptance criteria.
The benchmark covers marketing and content pages. It does not treat application backends, authentication, databases, dashboards, payments, or custom server logic as a visual page-conversion problem.
No result will be labelled “passed” because the page merely looks correct. The required editing and handoff checks must also pass.
Ten-case test matrix
The first round is designed to cover different source structures rather than ten versions of the same landing page. Exact source files and permission status will be linked when each result is published.
| Case | Source type | Required stress point |
|---|---|---|
| 01 | Single-file static HTML | Semantic headings, links, one image, and a primary CTA. |
| 02 | HTML/CSS/JS ZIP | Local assets, custom font, responsive menu, and script paths. |
| 03 | Multi-page HTML site | Shared navigation, active states, internal links, and page metadata. |
| 04 | Lovable marketing page | Responsive sections, repeated cards, and clear separation from app logic. |
| 05 | Claude-generated front end | Project assets, framework/build dependencies, and editable text regions. |
| 06 | Bolt marketing site | Routes, shared components, navigation, and external service boundaries. |
| 07 | GoHighLevel funnel page | Form replacement, tracking inventory, and CTA destination checks. |
| 08 | Framer landing page | Typography, breakpoints, animation inventory, and content editing. |
| 09 | Webflow content page | CMS boundary, redirect list, form handling, and responsive fidelity. |
| 10 | Media-heavy AI page | Image weight, lazy loading, page stability, and mobile performance. |
Procedure for every case
- 01
Freeze and document the source
Record the public URL or checksum of the supplied archive, viewport references, required interactions, source size, and anything removed for privacy.
- 02
Record preparation work
Time every action required before conversion: export, ZIP cleanup, missing assets, route selection, credentials removal, and unsupported-feature inventory.
- 03
Create the WordPress draft
Record time to the first reviewable result, the WordPress environment, active theme and plugins, and any failed attempt or retry.
- 04
Run visual and functional checks
Compare agreed desktop and mobile widths; inspect navigation, links, images, fonts, scripts, forms, metadata, and interactive states.
- 05
Perform the editability task
A second person changes a headline, paragraph, image, button URL, repeated item, and metadata field without help from the original converter operator.
- 06
Publish the remaining work
List manual repairs, dependencies, unsupported functionality, launch blockers, and total time to a handoff-ready result.
Measures and scoring
Did a draft finish?
Completed, partially completed, or failed—with the exact failure point and retry count.
How long to handoff-ready?
Preparation, automated processing, manual cleanup, review, and total elapsed time are reported separately.
Could another person edit?
Each required change is marked pass, pass with assistance, or fail, with the interface and dependency recorded.
What visibly changed?
Desktop and mobile differences are documented by category instead of compressed into a vague percentage.
What still works?
Navigation, links, forms, scripts, and key interactions are checked individually.
What does the site depend on?
Plugins, editor layers, external services, custom code, hosting assumptions, and export or backup paths are listed.
No composite “AI score” is used. Separate measures make it possible to see whether a fast result was difficult to edit or whether a faithful result required extensive cleanup.
Results publication policy
- Publish failures and partial results, not only successful showcase examples.
- Link the source when licensing and client permission allow it; otherwise explain exactly why it cannot be shared.
- Keep operator time separate from automated processing time.
- Show the editing task and identify the person’s prior WordPress experience.
- Record product version, date, plan, WordPress version, theme, plugins, and hosting conditions.
- Correct the page publicly if a reproduced result contradicts the original record.
The attachment asks for evidence-led content. Publishing invented successes would undermine that goal. The honest next milestone is ten documented cases with source evidence, recordings, and limitations—not a filled table without the underlying tests.
Reproduce or challenge the test
Reviewers may use this protocol for Tahmir, WPConvert, a manual rebuild, an AI-generated theme, or another conversion workflow. Use the same source, WordPress environment, viewport widths, content changes, and timing rules for every option.
To propose a source case or request test access, email hello@tahmir.ai. There is no requirement to publish a positive result.
Protocol version 1.0 · Published September 20, 2026 · Owner: Awais / Tahmir AI. Material changes to measures or pass criteria should be dated before new cases are compared with earlier results.
