AI-Generated WordPress Code Review Checklist

AI can help you build WordPress features faster. It will generate PHP snippets, CSS fixes, JavaScript, WooCommerce hooks, .htaccess rules, custom templates, even whole theme structures. But AI-generated code should not go straight into a live site without review. A snippet can look correct and still break checkout, forms, redirects, AJAX, the REST API, login, the mobile layout, or plugin compatibility, and the risk climbs when the code touches WooCommerce, server rules, user data, payments, or theme structure.

This checklist gives you a practical way to review AI-generated WordPress code before it goes near functions.php, a snippets plugin, a custom plugin, .htaccess, WooCommerce hooks, theme templates, or your JS and CSS. The goal is not to stop using AI. It is to use it safely.

Why AI-Generated WordPress Code Needs Review

A real WordPress site is rarely simple. It usually runs a theme or child theme, several plugins, often WooCommerce, contact forms, caching, an SEO plugin, a security plugin, custom snippets, server rules, the REST API, AJAX requests, user roles, login behaviour, mobile layouts, and third-party scripts. AI may generate code that works in a clean example and fails inside that real setup: a PHP snippet that warns during checkout AJAX, a redirect that loops, an .htaccess rule that blocks WooCommerce requests, JavaScript that clashes with WooCommerce scripts, CSS that hides checkout fields, a template missing wp_head() or wp_footer(), or a function name that collides with another plugin. A quick review prevents hours of emergency debugging later.

1. Understand What the Code Is Supposed to Do

Before adding anything, write the purpose in one sentence:

Make the WooCommerce phone field required.

If you cannot explain the purpose that clearly, do not add the code yet. Ask what exact problem it solves, which page or feature it should affect, which files it changes, whether it is a design, functionality, or server-level change, who it affects (visitors, admins, customers, or everyone), and whether it needs to run everywhere or only on one page. Good code has a clear scope.

2. Check Where the Code Should Go

AI often says “add this to functions.php.” That is not always the best answer, and placement matters.

Theme-related code

Use theme files for layout, template structure, frontend design, menu locations, theme support, and asset loading: header.php, footer.php, front-page.php, page.php, functions.php, and the assets/ folders.

Business logic

Use a small custom plugin for checkout business rules, order metadata, custom redirects, form processing, user role logic, custom post types, and reusable functionality.

WooCommerce changes

Use WooCommerce hooks and filters for checkout fields, order received text, email metadata, product display changes, and cart behaviour.

Server rules

Use .htaccess only when the change truly belongs at server level. Before adding code, ask whether this is theme behaviour or site functionality, whether it would disappear if the theme changes, whether it is safer as a custom plugin, and whether it is a server-level or WordPress-level problem. Wrong placement makes the site harder to maintain.

3. Check Whether the Code Uses WordPress Hooks Correctly

WordPress code usually runs through hooks. Common ones:

init
wp_loaded
wp_enqueue_scripts
template_redirect
wp_head
wp_footer
admin_init
save_post

WooCommerce hooks include:

woocommerce_checkout_fields
woocommerce_before_checkout_form
woocommerce_after_checkout_form
woocommerce_thankyou
woocommerce_email_order_meta
woocommerce_checkout_update_order_meta

The hook controls when the code runs. The wrong one makes it run too early, too late, on the wrong page, during AJAX, during admin requests, before WooCommerce is available, or after output has already started. This redirect is too broad:

add_action('init', function() {
    wp_redirect(home_url('/login/'));
    exit;
});

A safer version needs conditions:

add_action('template_redirect', function() {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    if (is_user_logged_in()) {
        return;
    }

    if (is_page('login')) {
        return;
    }

    wp_safe_redirect(home_url('/login/'));
    exit;
});

Before using AI hook code, check that the hook is appropriate, that it runs only where needed, that it will not affect AJAX, REST API, or admin, that it does not depend on WooCommerce being loaded too early, and that it does not output anything before it should.

4. Check Variable Safety

AI-generated PHP often assumes data exists:

$id = $_GET['id'];

This warns if id is missing. Safer:

$id = isset($_GET['id']) ? absint($_GET['id']) : 0;

Check every external data source: $_GET, $_POST, $_REQUEST, $_SESSION, $_COOKIE, $order->get_meta(), get_option(), and get_user_meta(). Ask whether the key exists, what happens if it is missing, whether the value is the expected type, whether there is a fallback, and whether it could create a PHP warning. Small warnings can break AJAX and WooCommerce checkout responses.

5. Check Sanitization

Sanitization means cleaning input before storing or using it. Common functions:

sanitize_text_field()
sanitize_email()
sanitize_key()
sanitize_title()
absint()
esc_url_raw()
wp_kses_post()

Bad:

$name = $_POST['name'];
update_option('customer_name', $name);

Better:

$name = isset($_POST['name']) ? sanitize_text_field(wp_unslash($_POST['name'])) : '';
update_option('customer_name', $name);

Match the function to the data type, and before using AI code ask whether it processes user input, saves data, reads from URL parameters or form data, and sanitizes based on type. If not, review it before deployment.

6. Check Escaping

Escaping makes output safe before it is displayed. Bad:

echo '<p>' . $message . '</p>';

Better:

echo '<p>' . esc_html($message) . '</p>';

For attributes use esc_attr(), for URLs use esc_url():

echo '<a href="' . esc_url($url) . '">Visit page</a>';

For limited safe HTML use wp_kses_post(). Ask whether the code prints dynamic data, whether the output is escaped, whether the escaping function fits, and whether user input could be printed to the page. AI examples skip escaping for simplicity; production code should not.

7. Check Function Names

AI often generates generic names like custom_checkout_fields(), which can collide with another plugin or snippet and cause:

Fatal error: Cannot redeclare custom_checkout_fields()

Use unique prefixes, for example webnorly_custom_checkout_fields() or a project-specific wn_fix_checkout_phone_field(). Check that function names, class names, and constants are unique, that CSS classes are unlikely to conflict, and that JavaScript global variables are avoided.

8. Check Plugin Dependencies

AI code may call plugin functions that only exist when the plugin is active:

WC()->cart->get_cart();

Guard it:

if (!function_exists('WC') || !WC()->cart) {
    return;
}

WooCommerce conditionals like is_product() may not exist if WooCommerce is disabled, so check first:

if (function_exists('is_product') && is_product()) {
    // code
}

Check whether the code depends on WooCommerce, Elementor, Contact Form 7, ACF, WPML or Polylang, membership plugins, payment plugins, or custom post types, and what happens if that plugin is disabled or updated. This prevents fatal errors.

9. Check AJAX and REST API Safety

This is critical for WordPress and WooCommerce. Some requests expect JSON, so code that outputs HTML, warnings, or debug text during them can break the feature. Avoid this:

add_action('init', function() {
    echo 'Debugging...';
});

And do not leave these in live code:

var_dump($data);
print_r($order);
die();

Prefer the log:

error_log(print_r($data, true));

Check whether the code echoes anything globally, whether it could run during AJAX or REST API requests, and whether it could add warnings before JSON output. Useful guards:

if (wp_doing_ajax()) {
    return;
}

if (defined('REST_REQUEST') && REST_REQUEST) {
    return;
}

Use these only when appropriate, but always think about dynamic requests.

10. Check Redirect Logic

Redirect snippets can be dangerous. This redirects everything:

add_action('template_redirect', function() {
    wp_redirect(home_url('/login/'));
    exit;
});

It can break the homepage, login page, admin area, checkout, cart, AJAX, REST API, payment gateway returns, and thank-you pages. A safer redirect has clear exclusions:

add_action('template_redirect', function() {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    if (is_user_logged_in()) {
        return;
    }

    if (is_page('login')) {
        return;
    }

    wp_safe_redirect(home_url('/login/'));
    exit;
});

Check that it uses wp_safe_redirect(), calls exit afterwards, excludes admin and AJAX and the target page, will not affect checkout or payment return URLs, and cannot create a loop.

11. Check .htaccess Rules Carefully

AI-generated .htaccess deserves extra caution, because a small rewrite affects every request before WordPress loads:

RewriteRule ^$ /home.html [L]

This can force the homepage to a static file and interfere with dynamic requests depending on the full rule context. That exact pattern is what we traced in a checkout case where the rewrite intercepted WooCommerce AJAX. Check whether the rule could affect:

/wp-admin/
/wp-login.php
/wp-json/
/cart/
/checkout/
/my-account/
/?wc-ajax=

Before changing .htaccess, make a backup, change one thing at a time, test permalinks, login, and checkout if WooCommerce exists, clear cache, and confirm there are no redirect loops. For many problems, a WordPress-native solution is safer than a server rewrite.

12. Check CSS Scope

AI-generated CSS can look fine but reach too far:

button {
    display: none;
}

That could hide buttons across the whole site, including checkout. This is also risky:

input {
    width: 100%;
    border: none;
}

It can affect search, checkout, login, and other forms. Scope it instead:

.woocommerce-checkout .form-row input {
    width: 100%;
}

Check whether selectors are too broad, whether they affect WooCommerce, forms, or mobile, whether they hide important elements, and whether they create horizontal scrolling. CSS should be scoped to the section or page it is meant to change.

13. Check JavaScript Dependencies

AI JavaScript may assume elements exist or libraries are loaded. Bad:

document.querySelector('.menu-button').addEventListener('click', function() {
    document.querySelector('.menu').classList.toggle('open');
});

If .menu-button does not exist, this throws an error. Safer:

const menuButton = document.querySelector('.menu-button');
const menu = document.querySelector('.menu');

if (menuButton && menu) {
    menuButton.addEventListener('click', function() {
        menu.classList.toggle('open');
    });
}

Check whether the script verifies elements exist, whether it depends on jQuery and whether jQuery is available, whether it runs before or after the DOM, whether it conflicts with WooCommerce scripts, and whether it is enqueued properly. Use wp_enqueue_script() rather than hardcoding scripts into templates.

14. Check WooCommerce-Specific Impact

WooCommerce is sensitive because checkout is dynamic. Before adding AI code, check whether it affects the cart session, checkout fields, payment or shipping methods, order total, coupons, order creation, the thank-you page, emails, or account pages. For checkout field changes, use the filter:

add_filter('woocommerce_checkout_fields', function($fields) {
    return $fields;
});

For thank-you page messages, use the hook with a guard and escaping:

add_action('woocommerce_thankyou', function($order_id) {
    if (!$order_id) {
        return;
    }

    echo '<div class="custom-thankyou-message">';
    echo esc_html__('Thank you for your order.', 'textdomain');
    echo '</div>';
});

After adding WooCommerce code, always test the full path, not just whether the checkout page loads:

Product → Cart → Checkout → Payment → Order Received → Email

15. Check Performance Impact

AI code may work but still slow the site. Watch for database queries on every page, external API calls on page load, large inline scripts, assets loaded everywhere, heavy loops, repeated get_posts() or WP_Query calls, and expensive operations with no caching. This is a bad pattern:

add_action('wp_footer', function() {
    $orders = wc_get_orders(array('limit' => -1));
    // output something
});

Ask whether it runs on every page, whether it queries the database or loads external resources, whether it can be limited to one page, whether results can be cached, and whether logged-out users even need it. Code should solve the problem without slowing the site.

16. Check Security and Permissions

If the code changes settings, saves data, processes forms, or performs admin actions, it needs permission checks (often current_user_can('manage_options')) and nonce verification. Bad:

if (isset($_POST['save_settings'])) {
    update_option('my_setting', $_POST['my_setting']);
}

Better:

if (isset($_POST['save_settings'])) {
    check_admin_referer('save_my_settings');

    if (!current_user_can('manage_options')) {
        return;
    }

    $value = isset($_POST['my_setting']) ? sanitize_text_field(wp_unslash($_POST['my_setting'])) : '';
    update_option('my_setting', $value);
}

Ask whether any visitor can trigger it, whether it requires login or an admin capability, whether a nonce is needed, and whether input is sanitized and output escaped. AI often writes simplified examples that skip these details.

17. Check Translation Readiness

On multilingual or non-English sites, hardcoded text causes problems. Bad:

echo 'Thank you for your order.';

Better:

echo esc_html__('Thank you for your order.', 'webnorly');

For dynamic text:

printf(
    esc_html__('Order number: %s', 'webnorly'),
    esc_html($order_number)
);

Check whether frontend text is hardcoded, whether the site uses multiple languages, whether the text domain is correct, and whether the text should be editable in admin instead.

18. Check Error Handling

Good code fails safely. Ask what happens if data is missing, if an API fails, if the plugin is inactive, if the user is not logged in, if the cart is empty, or if the order ID is invalid. Bad:

$order = wc_get_order($order_id);
echo $order->get_billing_email();

If $order is false, this breaks. Better:

$order = wc_get_order($order_id);

if (!$order) {
    return;
}

echo esc_html($order->get_billing_email());

AI code often assumes the happy path. Real WordPress code should handle the failure paths too.

19. Test on Staging First

The safest place to test AI-generated code is a staging site, where you can catch PHP errors, layout changes, checkout problems, mobile issues, plugin conflicts, redirects, and cache behaviour without risking the live site. For WooCommerce this matters most, because checkout problems cost real orders. Before deploying to live: back up files and database, test on staging, document the changed files, deploy during low traffic, clear cache, and retest the critical flows.

20. Keep a Rollback Plan

Before adding AI code, know how to undo it: a full site backup, a Git commit, a copy of the old file, a disabled snippet, or a backup of .htaccess. For small changes, keep a copy like:

functions-before-ai-snippet.php
.htaccess-backup-before-ai-rule

For bigger projects, use Git. A rollback plan turns a risky change into a controlled one.

Quick AI WordPress Code Review Checklist

Before adding AI code, confirm:

• I understand what the code does.
• I know where the code should go.
• It uses the correct WordPress hook.
• It runs only where needed.
• Variables are checked before use.
• User input is sanitized.
• Output is escaped.
• Function names are unique.
• Plugin dependencies are checked.
• It does not output during AJAX or REST requests.
• Redirects have safe conditions.
• .htaccess changes are backed up and tested.
• CSS selectors are scoped.
• JavaScript checks elements before using them.
• The WooCommerce flow is preserved.
• Performance impact is acceptable.
• Permissions and nonces are used where needed.
• Text is translation-ready where relevant.
• Errors are handled safely.
• It was tested on staging, and there is a rollback plan.

If even one important item is unclear, pause and review the code before going live.

What To Do If AI Code Already Broke Your Site

If the site breaks after adding AI-generated code, work through it in order:

1. Remove or disable the last change.
2. Restore the previous file if needed.
3. Check the PHP error logs.
4. Clear cache.
5. Test the broken flow again.
6. Review the code before re-adding it.
7. Avoid stacking more AI snippets on top of the broken one.

Common places to check:

functions.php
Code Snippets plugin
custom plugin files
.htaccess
theme templates
assets/js/
assets/css/

If the admin area is inaccessible, use your hosting File Manager or FTP to remove the code manually.

Final Thoughts

AI-generated WordPress code can be helpful, but it should go through the same review as any other code, and the faster it is generated, the more the review matters. A good review checks placement, safety, hooks, context, security, plugin compatibility, WooCommerce impact, performance, mobile behaviour, and the rollback plan. AI helps you build faster, but WordPress still needs structure, testing, and careful implementation.

---

If you have AI-generated WordPress code and are not sure whether it is safe, Webnorly can review it, clean it up, and help you apply it without breaking your site. Send us the code and we’ll check it against your real setup before it goes live.