Convert Codebases to Pixel-Perfect WordPress Themes

Codebase to WordPress Converter performs high-fidelity conversion of static or React-based frontends into fully functional, CMS-driven WordPress themes, acting as a senior WordPress architect, React expert, and QA engineer to achieve a 100% pixel-perfect match while integrating WordPress functionality like ACF, dynamic menus, and technical SEO preservation. It follows a strict four-phase forensic process: Phase 1 Forensic UI Comparison (a side-by-side table audit of React components versus WordPress templates, detection only, no fixes allowed at this stage); Phase 2 Full Audit (UI, SEO, CMS editability, navigation, functionality, and performance); Phase 3 Action Plan (tasks classified as SAFE, RISKY, or BLOCKED to prevent breaking the UI); and Phase 4 Iterative Fixing (one safe task executed at a time with validation after each step, confirming no UI change, no DOM change, and no class change). An absolute UI lock enforces non-negotiable rules: no alterations to layout, spacing, typography, or colors; exact preservation of Tailwind or CSS class names; and zero changes to DOM structure or HTML nesting.

Use this skill when converting a React (CRA/Vite/Next.js) or HTML project into a WordPress theme, when a client demands a 100% pixel-perfect match with the original source, when auditing an existing WordPress conversion for structural or SEO flaws, or when technical SEO (schema, meta tags, heading hierarchy) must be preserved exactly.

Given a source codebase, the skill outputs a WordPress theme with strategic field mapping (static text replaced with the_title(), get_field(), or the_content(); static paths replaced with get_template_directory_uri()) and correctly implemented core hooks (wp_head() before </head> and wp_footer() before </body> in header.php/footer.php; get_header() and get_footer() called in page templates; register_nav_menus() for dynamic navigation without altering the original HTML structure). A worked example shows the correct navigation-menu conversion, preserving the original Tailwind classes and a custom walker instead of the wrong wrapper-adding default:

// WRONG: Static replacement that adds wrappers
wp_nav_menu(['theme_location' => 'primary']);

// CORRECT: Preserving original Tailwind classes and structure
wp_nav_menu([
    'theme_location' => 'primary',
    'container' => false,
    'items_wrap' => '<ul class="flex space-x-8">%3$s</ul>',
    'walker' => new Custom_Tailwind_Walker()
]);

A live tracker maintains total, fixed, and remaining issue counts throughout Phase 4.

Built on WordPress theme conventions (ACF for custom fields, register_nav_menus, get_template_directory_uri) and Tailwind CSS preservation. Best practices: use get_page_by_path() for robust internal linking, implement ACF fallbacks in functions.php, and keep the Tailwind configuration in header.php so global styles stay active - while never adding div wrappers or renaming classes to "clean up" the code, and never falling back to default WordPress styles that conflict with the original design. Points to the ACF documentation, Tailwind CSS in WordPress guide, and the WordPress Theme Handbook.

Agencies and developers converting a React or static HTML site into a pixel-perfect WordPress theme who need forensic-level UI comparison, a safe/risky/blocked task classification to avoid breaking the design, and concrete hook/field-mapping patterns rather than a generic theme conversion checklist.