If you are a WordPress developer, an agency engineer, or a security-conscious site owner building and maintaining JavaScript-heavy WordPress sites, understanding this cybersecurity landscape is non-negotiable. If your code gets it wrong, attackers can seamlessly hijack user sessions, scrape sensitive data, or execute various hacks to seize control of your site entirely. 

The scale of this threat isn’t theoretical. In March 2025, security researchers reported that more than 1,000 WordPress sites were loading malicious third-party JavaScript that established four separate backdoors, giving attackers multiple ways to maintain access to compromised sites.

Secure JavaScript development comes down to managing three critical risk pillars: how you handle user input, which scripts you choose to trust, and what data you expose to the browser.

What Is JavaScript security?

At its core, JavaScript security is the practice of writing, loading, and configuring JavaScript to reduce the risk of unauthorized code execution, data exposure, account compromise, and abusive browser behavior.

JavaScript running on a page can access the Document Object Model (DOM), Web Storage API, data exposed to the page, and cookies that have not been marked HttpOnly. Cookies configured with HttpOnly cannot be read through JavaScript APIs such as document.cookie, although the browser may still include them automatically with applicable requests. If malicious JavaScript executes on the page, it may be able to modify visible content, access browser storage, capture data entered by users, redirect visitors, or perform authenticated actions using the victim’s active session.

The security equation gets uniquely complicated in the WordPress content management system ecosystem. A standard WordPress site often concurrently executes JavaScript bundled into WordPress core, active themes, numerous active plugins, and a web of third-party external tracking scripts. Every single one of these scripts functions as an independent, potential entry point to your user’s browser.

Common JavaScript security risks in WordPress

While the web is full of diverse digital threats, the vast majority of client-side vulnerabilities in WordPress boil down to a handful of recurring categories.

Cross-site scripting (XSS)

Cross-site scripting (XSS) is the single most prevalent browser-side vulnerability in modern web development. An XSS vulnerability occurs when an attacker successfully injects a malicious payload into a legitimate, trusted website, using the application as a delivery vehicle to execute rogue scripts on an unsuspecting user. XSS primarily manifests in three distinct flavors:

• Stored XSS: The malicious payload is permanently saved into the site’s database (e.g., via a compromised comment section or user profile field) and executed every time a user views the infected page.
• Reflected XSS: The malicious script is embedded directly into a volatile request, such as unsanitized URL query parameters, requiring the target to click a rigged link.
• DOM-based XSS: The vulnerability exists entirely within the client-side code itself, where your JavaScript unsafely processes and executes data from the local environment without ever involving a server-side cycle.
  

In WordPress, XSS commonly sneaks in through unsanitized input fields within contact forms, comment sections, custom plugin settings panels, or poorly managed URL variables.

WordPress output-escaping functions such as esc_html(), esc_attr(), esc_url() remain essential for server-rendered content. However, escaping must match the output context and should be performed as late as possible, immediately before rendering. When JavaScript dynamically modifies the DOM, prefer APIs such as textContent, .createElement(), and .append(), which treat strings as text rather than HTML. If dynamic HTML is genuinely required, sanitize it before inserting it into the page.

Malicious or compromised third-party scripts

Modern websites are assembled like puzzles, often relying on external Content Delivery Networks (CDNs), ad platforms, analytics frameworks, custom web fonts, and various dynamic scripts. However, loading scripts from third-party ecosystems exposes you to supply chain risks.

If a trusted external network or plugin repository is breached at the source, attackers can quietly alter those scripts to inject malicious payloads directly across your entire site layout. This threat compounds when sites rely on complex JavaScript-loader chains, where one script dynamically pulls down several others. In WordPress, every script dependency you add expands your attack surface; if you don’t actively vet your plugins and connections, you are implicitly trusting every developer down that supply chain.

Insecure JavaScript functions

Many client-side vulnerabilities are accidentally self-inflicted through the use of risky legacy functions. Here are the key culprits to actively scrub from your codebase:

• eval(): This function parses any plain string passed to it and executes it directly as active JavaScript code. If attacker-controlled input reaches eval(), the attacker may gain arbitrary JavaScript execution within the security context of the affected page. That code may be able to read or modify page content, access browser storage available to the origin, and perform authenticated requests with the user’s browser session. You should drop it entirely in favor of secure alternatives like JSON.parse() for incoming JSON strings.
• document.write(): This legacy method directly injects markup into the page loading cycle and is notoriously trivial to exploit for DOM-based XSS.
• innerHTML and jQuery’s .html(): These methods interpret strings as HTML and are dangerous when those strings contain untrusted data. Although <script> elements inserted through innerHTML generally do not execute, attackers can still execute JavaScript through event-handler attributes, malicious URLs, SVG content, and other forms of active markup. Prefer textContent and programmatic DOM construction when HTML interpretation is not required. 
• setTimeout() and setInterval() with string parameters: Passing a raw string to these timing functions forces the engine to evaluate it exactly like an eval() call. Always pass direct function references instead.

Insecure cookie handling

Session and authentication cookies act as your passport on the web. If a session cookie is accessible to JavaScript, a successful XSS attack may be able to read and exfiltrate it, potentially enabling session hijacking. Marking the cookie HttpOnly prevents direct JavaScript access to its value. However, HttpOnly does not prevent malicious JavaScript already executing on the trusted origin from making authenticated requests, because the browser may still attach the cookie automatically.

CSRF is a separate attack in which another site tricks an authenticated user’s browser into making an unwanted request. SameSite cookies and WordPress nonces can help mitigate CSRF, but an active XSS vulnerability can often bypass normal CSRF defenses because the malicious code is executing within the trusted site.

To safeguard cookies from JavaScript interception, you must enforce proper attributes:

• HttpOnly: This server-side flag ensures that the cookie is completely invisible to client-side scripts, neutralizing cookie theft via XSS. While WordPress core correctly secures its authentication cookies with this flag out of the box, any custom cookies generated by your plugins or themes require explicit configuration.
• Secure: This forces the browser to transmit the cookie exclusively over encrypted HTTPS connections.
• SameSite: This controls when a browser includes a cookie with cross-site requests. SameSite=Strict provides the strongest restriction but may interfere with legitimate navigation and authentication workflows. SameSite=Lax permits cookies in certain top-level navigation scenarios while blocking many other cross-site uses. Because SameSite is only a partial CSRF defense, sensitive operations should still use appropriate request-verification controls.

For sensitive session and authentication identifiers, always configure them server-side using HTTP headers so you can apply the HttpOnly flag and the secure __Host- prefix:

Set-Cookie:__Host-session=<opaque-session-id>; Path=/; Secure; HttpOnly; SameSite=Lax

When handling genuinely non-sensitive client preferences directly within JavaScript (such as saving a user’s theme selection), enforce encryption and scope restrictions without using session-related naming:

document.cookie = "theme=dark; Path=/; Secure; SameSite=Lax";

Additionally, remember to never store sensitive authentication tokens or user PII in local structures like localStorage that remain exposed to client-side script queries.

Exposed JavaScript APIs

Modern frontend scripts communicate constantly with backend services using the WordPress REST API or various external API endpoints. A major risk occurs when developers accidentally hardcode sensitive credentials, private API keys, or access tokens directly into their public, client-side files where anyone inspecting the code can copy them.

Furthermore, client-side validation alone is never a true security barrier. Use an authentication method appropriate to the client making the REST API request. For requests made from a logged-in WordPress interface using WordPress authentication cookies, include a REST API nonce to help protect against CSRF. A nonce does not authenticate a user or determine what that user is authorized to do.

Every protected custom REST route should define a permission_callback and perform server-side capability checks, commonly with current_user_can(). External and headless clients should use an appropriate authentication mechanism, such as WordPress Application Passwords over HTTPS or another carefully reviewed authentication system.

Plugin and theme vulnerabilities

The vast open-source nature of WordPress is its greatest strength, but it’s also a major source of security friction. Because anyone can publish a plugin or theme, the quality of JavaScript safety varies widely based on the creator’s security expertise.

Unpatched vulnerabilities in old or abandoned extensions are a primary target for automated web exploits. Mitigating this risk requires disciplined extension management. Before installing a plugin or theme, review its maintenance history, supported WordPress and PHP versions, recent releases, known vulnerability history, security-reporting process, developer responsiveness, and whether the extension is still necessary. Active installation counts and user reviews may provide useful context, but they should not be treated as evidence that an extension is secure.

Remove plugins and themes that are no longer required, maintain an inventory of installed components, monitor for published vulnerabilities, and apply security updates promptly after appropriate testing.

JavaScript security best practices for WordPress

Building a secure WordPress environment requires a layered defense strategy. Relying on a single security measure is never enough. True resilience in website security comes from combining clean coding habits with robust platform-level configurations. The following best practices are prioritized by their overall security impact.

1. Avoid direct HTML insertion in JavaScript

The single most effective defense against cross-site scripting is to completely avoid inserting raw HTML strings directly into the browser’s DOM. Methods such as innerHTML and jQuery’s .html() are HTML injection sinks. Passing untrusted strings to them can create DOM-based XSS vulnerabilities through event handlers, dangerous URL schemes, SVG markup, and other executable HTML constructs.

Instead, construct your user interface elements programmatically using safe, native DOM generation methods like createElement, createTextNode, appendChild, or append. These native tools treat content strictly as data text rather than executable markup.

If you are working within modern component frameworks like React, avoid utilizing attributes like dangerouslySetInnerHTML unless it is absolutely necessary. If you encounter an edge case where dynamic HTML rendering cannot be avoided, you must pass the string through a specialized client-side sanitization script first.

// BAD PATTERN: Vulnerable to XSS if the API response is manipulated
const userSnippet = response.userData; 
jQuery('#user-profile').html("<p>" + userSnippet + "</p>");

// GOOD PATTERN: Safe DOM construction that treats input strictly as data
const profileContainer = document.getElementById('user-profile');
const paragraphElement = document.createElement('p');
paragraphElement.textContent = response.userData; 
profileContainer.appendChild(paragraphElement);

2. Sanitize user input on both sides

Comprehensive application security requires input validation and sanitization at both ends of the data pipeline. On the server side, validate incoming data against the expected format whenever possible. If strict validation is not possible, sanitize the input before processing or storage using the appropriate WordPress function, such as sanitize_text_field() for plain text or wp_kses() when a controlled subset of HTML is allowed.

However, server-side scrubbing alone does not secure data that is manipulated dynamically on the client side. When handling raw data within JavaScript, protect your execution context by utilizing an industry-standard client-side library like DOMPurify to strip out malicious payloads before rendering any dynamic elements.

Validation checks whether data matches the expected format. Sanitization cleans data when strict validation is not possible. Escaping makes data safe for a specific output context at rendering time. These controls serve different purposes and should not be treated as interchangeable

3. Implement a content security policy

A content security policy (CSP) is an HTTP header configured on your web server that establishes a strict set of rules telling the user’s browser exactly which sources of scripts, styles, layouts, and external resources are allowed to load and execute.

A well-configured CSP serves as an excellent security layer. Even if an attacker uncovers an open XSS vulnerability on your site and injects a malicious payload, the browser will consult your policy, recognize the script origin as unauthorized, and block it from executing.

You can inject a CSP header through your wp-config.php file, your theme’s functions.php file, or directly within your hosting server configuration files (such as .htaccess for Apache or nginx.conf for Nginx). A standard baseline policy looks similar to this:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com 'nonce-2726x';

This specific rule dictates that by default, resources must originate strictly from the site’s own domain, while explicitly granting JavaScript execution rights only to the site itself and Google’s trusted API endpoint.

Be aware that an overly aggressive CSP can break existing plugins or tracking systems that rely on inline scripts. When deploying a new policy, always run it in Content-Security-Policy-Report-Only mode first to catch and log errors without disrupting the frontend user experience.

4. Consider Trusted Types for additional DOM XSS protection

Trusted Types provide an additional browser-enforced defense against DOM-based XSS. When enabled through Content Security Policy, Trusted Types can prevent application code from passing ordinary strings directly to dangerous DOM injection sinks such as innerHTML.

Instead, code must create approved values through a Trusted Types policy. For HTML content, the policy can use a sanitizer such as DOMPurify on GitHub before producing a TrustedHTML value.

A simplified policy example here:

</>http

Content-Security-Policy:
  require-trusted-types-for 'script';
  trusted-types app-html;

const htmlPolicy = trustedTypes.createPolicy('app-html', {
  createHTML: (input) => DOMPurify.sanitize(input),
});

element.innerHTML = htmlPolicy.createHTML(untrustedHTML);

5. Use subresource integrity for external scripts

To protect your site from supply chain attacks, you should implement subresource integrity (SRI) whenever you link to scripts hosted on external third-party servers or CDNs. SRI allows you to attach a specific, cryptographic hash value directly onto your script tags.

When the user’s browser fetches the script from the external source, it hashes the downloaded file and compares it to your defined string. If a bad actor compromises that external network and inserts a malicious backdoor into the file, the hashes will fail to match, and the browser will refuse to load the script.

<script src="https://cdn.example.com/library-v1.js" 

        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8mC" 

        crossorigin="anonymous"></script>

Keep in mind that SRI is intended exclusively for static, version-controlled scripts. It cannot be used on dynamic scripts or endpoints whose underlying code changes frequently.

6. Secure cookies properly

To neutralize session hijacking and unauthorized Cross-Site Request Forgery (CSRF) attempts, you must explicitly isolate your cookies from unauthorized browser contexts.

Ensure your server-side scripts assign the HttpOnly attribute to all critical authentication and session identifiers. While WordPress core applies this setting natively to standard user logins, custom plugin cookies require explicit assignment.

Additionally, always attach the Secure flag to ensure cookies are transmitted exclusively over encrypted HTTPS networks, and set the SameSite attribute to Strict or Lax to prevent cookies from being passed to external or cross-origin requests. Avoid placing highly sensitive data, access keys, or user credentials inside accessible cookies or browser localStorage where client-side JavaScript can freely query them.

7. Audit third-party scripts and dependencies

Every plugin, theme, or tracking pixel you load introduces code from an external developer into your environment, expanding your site’s attack surface. Mitigate supply chain risks by performing routine, scheduled audits of all internal and external dependencies.

Utilize automated security infrastructure tools such as WPScan or Wordfence to track core file changes, perform malware scanning, and scan for known plugin vulnerabilities. If your WordPress platform uses a headless design or relies on compilation tools, run npm audit to catch vulnerable dependencies inside your package.json files.

When managing extensions, remember that simply deactivating a plugin does not secure your site. You must completely delete the files to remove them from your server. Consider leveraging automated updating solutions like WP Engine’s Smart Plugin Manager to safely test and apply patches the moment security fixes are released.

8. Use HTTPS everywhere

Enforcing HTTPS across your entire application is a baseline security requirement. HTTPS uses Transport Layer Security (TLS) instead of the now outdated SSL to encrypt data traveling between the user’s browser and the web server, helping protect the connection against eavesdropping and modification. Serve the main document and all scripts, styles, images, API calls, and other subresources over HTTPS to avoid insecure mixed content.

Without complete HTTPS coverage, your site is highly vulnerable to man-in-the-middle (MITM) attacks, where interceptors can inject malicious JavaScript directly into an unencrypted session. Managed hosting environments often eliminate this barrier by supplying automated, free SSL certificates.

9. Limit JavaScript API surface

Do not reveal more data or infrastructure entry points to the browser than your application absolutely needs to function. Protect custom WordPress REST API routes with a properly implemented permission_callback, server-side capability checks, input validation, and the authentication mechanism appropriate to the client. Use a REST nonce when the request relies on WordPress cookie authentication, but do not treat the nonce as a replacement for authentication or authorization.

Most importantly, never expose permanent private API keys, client secrets, or sensitive cloud credentials within public, client-facing scripts. If a browser application requires access to a secured external API, route the approved operations through a server-side endpoint so that private credentials are never included in the client bundle. The endpoint must authenticate and authorize the requesting user, validate all input, restrict requests to approved destinations and operations, apply appropriate rate limits, avoid returning unnecessary upstream data, and log suspicious activity.

Do not create a general-purpose proxy that accepts an arbitrary destination URL. Without strict destination allowlists and request controls, a proxy can introduce server-side request forgery and credential-abuse risks.

10. Enable a web application firewall (WAF)

A WAF provides an essential protective perimeter around your site by evaluating incoming traffic patterns before they ever reach your web application layer. A WAF can detect and block many known malicious HTTP request patterns, including some common XSS payloads, automated abuse, brute force attacks, and other application-layer attacks. It provides a valuable defense-in-depth layer but does not repair vulnerable application code and cannot reliably identify every new or obfuscated payload.

For optimal performance, implement a WAF at the network edge rather than relying on heavy application-level WordPress security plugins. Edge-level sorting blocks malicious actors and DDoS attempts immediately, saving your server’s database resources and processing power for legitimate visitors. WP Engine offers Global Edge Security, which features a managed WAF built specifically to handle WordPress vulnerabilities.

11. Monitor and audit

Proactive real-time monitoring helps you catch and neutralize threats before they cause widespread damage. Deploy automated file integrity monitoring solutions to alert your team the moment unexpected edits or additions occur within your site’s directory tree.

Routinely review your web server logs for suspicious requests, repeated API errors, or unauthorized script-loading behavior. Utilizing centralized security dashboards provided by your hosting provider allows you to quickly pinpoint abnormalities and track potential indicators of compromise across your entire file layer.

JavaScript Security Scanners and Tools

Automated testing tools help you inspect your application from an external point of view to find vulnerabilities before hackers and attackers do. While automated scanners are highly effective at identifying known errors, they should complement a broader defense-in-depth security approach.

Consider integrating these security scanners into your workflow:

The managed hosting advantage for JavaScript security

Implementing every layer of JavaScript security manually can require significant development time and operational upkeep. A managed WordPress hosting architecture streamlines this process by embedding enterprise-grade security controls directly into the server infrastructure layer.

When you partner with a premium managed platform like WP Engine, you gain access to an infrastructure built around client-side safety:

• Edge-level protection: A managed WAF can block many known malicious request patterns before they reach WordPress, reducing exposure to common automated attacks. A WAF cannot prevent every XSS vulnerability, particularly DOM-based XSS that occurs entirely within browser-side JavaScript or attacks involving already trusted third-party scripts.
• Automated patch management: Systems like Smart Plugin Manager automatically track, test, and apply critical plugin patches to keep your site updated without breaking functionality.
• Proactive Continuous auditing: Dedicated security operations teams monitor platform traffic logs, track ecosystem developments, and apply server-level protection rules against zero-day vulnerabilities.
• Strict curated infrastructure: Curated disallowed-plugin filters block extensions with known vulnerabilities, keeping high-risk code out of your ecosystem.
• Secure defaults: Features like automated SSL certificate generation, secure default cookie attributes, and easy security header configuration give you a highly protected environment out of the box.

By delegating server management and edge security to a managed host, your development team can focus on writing clean application features rather than managing baseline infrastructure security. Client-side safety requires a unified approach: combine secure code habits with a protected server platform to keep your site resilient against modern web threats.

Ready to learn more? Explore WP Engine’s hosting plans to see how we protect your application.

FAQs about JavaScript security for WordPress

What Is the biggest JavaScript security risk for WordPress sites?

Cross-Site Scripting (XSS) is the most prominent threat. It enables attackers to inject malicious code into pages seen by other users, letting them hijack active browser sessions, compromise sensitive user data, or deface layouts. These scripts often infiltrate through unsecured plugin inputs or unvalidated URL parameters.

How do I prevent XSS attacks in WordPress JavaScript?

Avoid direct HTML string insertions like .innerHTML or .html() entirely. Instead, construct elements using safe native DOM manipulation methods like .createElement() and .textContent. For scenarios requiring dynamic HTML input from external sources, sanitize the data thoroughly using an industry-standard library like DOMPurify first.

What is a content security policy and why does it matter?

A content security policy (CSP) is an HTTP header restricting which script, style, and media sources the browser is authorized to execute. It serves as a powerful safety net; even if an attacker successfully injects a malicious script payload into your page, the browser will block it from running.

Are WordPress plugins a security risk?

They can be if they use outdated or insecure JavaScript logic. Because plugin development quality varies, unpatched software introduces cross-site scripting risks and supply chain backdoors. Protect your site by only installing highly-rated, actively updated plugins, and completely deleting any extensions you do not use.

How often should I audit my WordPress JavaScript dependencies?

Audits should be performed regularly as part of a routine maintenance schedule or integrated into your active development deployments. Utilize automated security utilities to immediately identify known script vulnerabilities, and keep your software environment continuously updated using automated update managers.

Does managed hosting protect against JavaScript attacks?

The right managed host helps by adding several layers of infrastructure-level defense. Managed platforms may provide a managed WAF that blocks many known injection attempts before they reach WordPress. This reduces risk. You must also include best practices around secure coding, dependency management, output escaping, CSP, or browser-side protections.

The post Solve These Common WordPress JavaScript Security Issues appeared first on WP Engine®.

To do that, websites use what are called “cookies.” Cookies on the web enable sites to store key information safely within visitors’ browsers. That way, they can provide a more personalized experience without putting user data at risk.

In this article, we’ll break down how cookies work and the ways WordPress in particular uses them. Then we’ll teach you how to set up custom cookies in WordPress. Let’s get to work!

What are cookies in WordPress?

Simply put, cookies are files that your website stores in visitors’ browsers, which contain information about them. Here are some common examples of cookie use throughout the web:

• Storing session information that has been authenticated using login credentials, so users don’t have to re-enter them each time they visit your site.
• Remembering specific pages that visitors have been looking at lately (i.e., “Recent products” on eCommerce sites).
• Noting specific user behavior, such as when they last visited your site.

Cookies are everywhere on the web, to the extent that there’s even specific legislation that governs how you can use them in some parts of the world.

Overall, browsing the web would be a slower and less personal experience without cookies. Websites wouldn’t be able to remember any of the information that makes your life easier. That’s why WordPress is set up to use cookies out of the box.

How WordPress uses cookies

By default, WordPress generates two types of cookies unless you tell it to do otherwise. Those include:

• Session cookies: These are the ones that tell your browser: “Hey, we just logged into this site a little while ago, let’s reuse that session.” That saves you from logging in over and over on the same sites.
• Comments cookies: Whenever you comment on a WordPress website, it will save some of your details so you don’t have to re-enter them later on. That can include your username, email address, and more.

How WordPress plugins use cookies

As you might imagine, WordPress plugins and other third-party tools also make extensive use of cookies. For example, if you use a related posts plugin, it probably takes advantage of cookies to store information about which pages users have viewed.

Likewise, analytics plugins tend to use cookies to store user behavior data. In most cases, these cookies are harmless. However, these days you might need to display a cookie notice on your website, depending on where you do business.

You’ve probably seen these cookie notices all around the web, and it’s no coincidence. People are more interested than ever in online privacy, so it only makes sense that many websites try to be as transparent as possible.

How to set cookies in WordPress

You’ll need to use PHP to create and set up cookies in WordPress. Where you add the necessary code depends on whether you want to use your theme or a custom plugin. Let’s take a look at how the first method works.

Step 1: Open your theme’s functions.php file

In most cases, the theme approach is the easiest route to take. To set a new cookie, you’ll want to edit your active theme’s functions.php file.

We should note that any changes you make to your theme should likely be done in a child theme. This ensures they won’t be wiped out when the parent theme is updated. 

Open your active theme’s folder, and look for the functions.php file inside. To add a custom cookie, you’ll need to include some additional code within this file. Before that, however, you need to understand what parameters you can use:

• The name of the cookie
• Its value
• How long until it expires (it can’t last forever!)
• Which pages the cookie will act on
• Your domain and/or subdomains
• Whether it should transfer over HTTP or HTTPS

We’re going to use these parameters within the next section, so don’t worry if you don’t fully understand what each of them does just yet.

Step 2: Add your new cookie’s code

Once you open the functions.php file, you’ll be able to add custom code to it. Here’s an example of the code you’d use to add a new cookie:e’s an example of the code you’d use to add a new cookie:

/**
 * Shared cookie settings.
 * Keeping these in one place helps ensure create/delete use the same path/domain/etc.
 */
function wpdocs_visit_cookie_options() {
    return array(
        // If WordPress defines a cookie path, use it; otherwise fall back to root.
        'path'     => ( defined( 'COOKIEPATH' ) && COOKIEPATH ) ? COOKIEPATH : '/',
        // Empty domain means "current host" behavior in most cases.
        'domain'   => defined( 'COOKIE_DOMAIN' ) ? COOKIE_DOMAIN : '',
        // Only send cookie over HTTPS when site is on SSL.
        'secure'   => is_ssl(),
        // Prevent JavaScript from reading this cookie (mitigates some XSS impact).
        'httponly' => true,
        // Good default for normal site navigation and basic CSRF protection.
        'samesite' => 'Lax',
    );
}

/**
 * CREATE: set visit_time once, storing a Unix timestamp.
 */
function wpdocs_set_visit_time_cookie() {
    // Cookies are sent in headers; bail if headers already went out.
    if ( headers_sent() ) {
        return;
    }

    // Only set on first visit (or until cookie expires).
    if ( isset( $_COOKIE['visit_time'] ) ) {
        return;
    }

    // Store Unix timestamp as a string.
    $value   = (string) time();
    // Expire in 24 hours.
    $expires = time() + DAY_IN_SECONDS;
    $opts    = wpdocs_visit_cookie_options();

    setcookie(
        'visit_time',
        $value,
        array(
            'expires'  => $expires,
            'path'     => $opts['path'],
            'domain'   => $opts['domain'],
            'secure'   => $opts['secure'],
            'httponly' => $opts['httponly'],
            'samesite' => $opts['samesite'],
        )
    );

    // Keep current request state in sync (browser receives cookie on next request).
    $_COOKIE['visit_time'] = $value;
}
// Run early so cookie headers are set before output.
add_action( 'init', 'wpdocs_set_visit_time_cookie', 1 );

That code includes the parameters we laid out in the last section. There’s the cookie name (cookies_timestamp), its value (visit_time), and how long until it expires. For additional information on configuring your cookie, see the PHP docs on setcookie.

This cookie generates a timestamp of the last time someone visited your site. You might then use the cookie to display a message such as, “Your last visit was on January 25th, 2019.” This lets users know if someone else has accessed their account.

As for the expiration time, you’ll notice it’s in seconds. We set the value for a day, which is pretty short by cookie standards. The rest of the parameters don’t matter as much, because the default options work well enough in almost every case.

When you’re done configuring your cookie, save the changes to functions.php. Once you deploy this code to your site using your regular methods, your cookie will start working right away!

How to get a cookie and use it in WordPress

In the last section, we talked about how you can use cookies in web development to store relevant user-specific data. There’s a specific function you can use to “get” cookies, so to speak. 

To use it, you’ll need to edit your theme’s functions.php file once more. Here’s a quick example:

/**
 * READ: return a formatted label from the visit_time timestamp.
 * Returns empty string when cookie is missing/invalid. 
 */
function wpdocs_get_visit_time_label() {
    // No cookie yet means first visit. 
    if ( empty( $_COOKIE['visit_time'] ) ) {
        return '';
    }

    // Unslash + cast to safe positive integer.
    $timestamp = absint( wp_unslash( $_COOKIE['visit_time'] ) );
    if ( ! $timestamp ) {
        return '';
    }

    // Format using WordPress date handling (timezone-aware).
    return wp_date( 'F j, Y g:i a', $timestamp );
}

/**
* Use the formatted date in your php as needed in a template file, theme action hook, shortcode, or block render callback.
*/
$last_visit = wpdocs_get_visit_time_label();
if ( $last_visit ) {
    echo '<p class="visit-time"><strong>Welcome back!</strong> Your last visit was on: ' . esc_html( $last_visit ) . '</p>';
}

In a nutshell, this creates a second function that checks to see if the visit_time cookie we created during the last section is there. If it is, then the code will return a formatted date for use in our theme.

Deleting a Cookie in WordPress

To delete a cookie, you can’t just clear it with PHP memory functions. You have to tell the visitor’s browser that the cookie has expired. You can achieve this by setting its expiration date to a time in the past.

To delete a cookie safely in WordPress, add the following code to your theme’s functions.php file: 

/**
 * DELETE: expire in the past using matching attributes.
 */
function wpdocs_delete_visit_time_cookie() {
    // Need headers + existing cookie to attempt deletion.
    if ( headers_sent() || ! isset( $_COOKIE['visit_time'] ) ) {
        return;
    }

    $opts = wpdocs_visit_cookie_options();

    setcookie(
        'visit_time',
        '',
        array(
            // Past timestamp tells browser to remove cookie.
            'expires'  => time() - HOUR_IN_SECONDS,
            'path'     => $opts['path'],
            'domain'   => $opts['domain'],
            'secure'   => $opts['secure'],
            'httponly' => $opts['httponly'],
            'samesite' => $opts['samesite'],
        )
    );

    unset( $_COOKIE['visit_time'] );
}


// Example hook:
// add_action( 'wp_logout', 'wpdocs_delete_visit_time_cookie' );

AAs always, remember that we’re using placeholders in our example. You’ll want to modify that code depending on your specific cookie’s name. Once the browser processes this script, the cookie will be permanently removed from the user’s system.

Conclusion

Cookies are one of the many ways modern websites can provide their users with a better experience. Using WordPress, you can configure cookies to personalize your site for each visitor.

If you want to learn about other techniques for improving the user experience, check out our developer resources, where you can find dozens of guides and tutorials. While you’re at it, improve your experience with a host specifically optimized for WordPress. Take a look at our plans—chances are you’ll find a great fit!

The post WordPress Cookies appeared first on WP Engine®.

Local solves this by turning your machine into a powerful offline server environment.

Developing locally grants total freedom. You can test plugins, tweak themes, and refactor code with zero risk to your live site. Paired with WP Engine hosting, Local transforms your laptop into a secure, lightning-fast, and high-performance sandbox.

This guide shows you how to master that ecosystem. You’ll learn everything from spinning up your first site to scaling your workflow with Blueprints and advanced CI/CD pipelines.

Getting started

Before diving into the code, you need to understand exactly what Local is and get comfortable navigating its interface.

What is Local Development?

Before installing the software, it helps to understand what Local actually does.

• Providing a sandbox environment: Normally, a WordPress website lives on a live web hosting server. Local transforms your own machine into an offline server, allowing you to build and test your site completely in private.
• No internet required: Because the server is running directly on a laptop, it’s possible to build, break, and experiment with a WordPress site offline, meaning WordPress development can be performed anywhere.
• Experiment with (and break) sites safely: If you install a plugin that crashes the site or triggers a critical PHP error, your live website remains completely untouched and safe. This makes it a great tool for testing and experimentation.

Installation & system preparation

Getting Local up and running is straightforward, but there are two things beginners should know before hitting download:

• Admin privileges: During installation, your operating system (Mac or Windows) will likely ask for your administrator password. This is normal and safe; Local needs permission to tweak your system’s hosts file so that custom web addresses (like mysite.local) work correctly in your browser.
• Disk space check: While the Local application itself is lightweight, every WordPress site you create includes its own database, core files, and media. Keep an eye on your hard drive space if you plan to clone large production sites later.

Spinning up a new site

To understand how professional teams collaborate without overwriting each other’s code, you need a clean baseline site to practice on. In this quick setup, we’re going to spin up a fresh local site and install a standard theme and plugin to mimic a real client project.

Prerequisites

• Ensure Local is downloaded and installed on your machine.
• Have your command line terminal handy (though we won’t need it just yet).

Getting started

1. Create the site:
   • Open Local, click the “+” icon (Create a New Site), and give it a name. At this point there are some advanced options, but these can be left as the default for now.
   • Choose the preferred standard environment, to use the default most up to date versions of PHP and MySQL.
   • Finally add a WordPress username and password

2. Launch the Admin Panel: Once the site is live, click the Admin button on your Local dashboard to jump straight to your WordPress login screen and log in with the details you set up previously.
3. Install the Baseline Theme: Go to Appearance – Themes – Add New, then search for, install, and activate the Frost theme (a clean block theme perfect for development testing) or a theme of your choice.
4. Install a Test Plugin: Go to Plugins – Add New, then search for, install, and activate any standard plugin of your choice.

Cloning a live site

Spinning up a blank website in Local is great for practice, but what happens when a client hands you an existing, live website with hundreds of blog posts and thousands of images?

Thanks to a tight integration between Local and the free WP Migrate Lite plugin, you can package up a live website into a single .zip file and clone it onto your computer in just a few clicks with no complex API keys or server pipelines required.

Prerequisites

• Install the free WP Migrate Lite plugin on the live website you want to clone.
• Ensure your Local desktop application is open on your computer.

Getting started

1. Export the live site: On your live WordPress dashboard, navigate to Tools – WP Migrate. Select the Full Site Export option to bundle your database, media library, themes, and plugins into a single package, and download the resulting .zip file.
2. Drag, drop, and clone: Take that downloaded .zip file and drag it directly anywhere onto the open Local desktop app window.
3. Automatic translation: Local will automatically read the zip package, unpack the files, and spin up a local copy.
4. The magic behind the scenes: During the import, Local uses WP Migrate to run an automatic Find and Replace on your database. It safely updates all your live URLs (like mywebsite.com) to local URLs (like mywebsite.local) and fixes any broken serialized data automatically.

Want to see the full walkthrough of this migration process or learn more about how WP Migrate handles complex database serialization?

Check out the full breakdown: Importing a Live Site with WP Migrate and Local.

The Local dashboard

When your new site finishes installing, you will be greeted by the Local dashboard. It can look intimidating with all its technical jargon, but you only need to know four main areas:

• The site control bar: This features the Start/Stop Site toggle. Local doesn’t need to drain your battery when you aren’t working; turn it on when you develop, and stop it when you’re done. You’ll also find the Admin button (takes you to the WordPress login) and the Open Site button (takes you to the website frontend).
• The overview tab: This shows your site’s vitals. Here, you can change your PHP Version on the fly to test compatibility. You can also toggle on One-Click Admin, a massive quality-of-life feature that automatically logs you into WordPress without making you type your password every time.
• The database tab: WordPress stores all your posts, pages, and settings in a database. Clicking Open Admin gives you a direct look into those database tables. You won’t need this often, but it’s a lifesaver if you ever need to manually fix a broken setting or edit data.
• The tools tab: This is where Local hides some of its best features, like Mailpit (an internal inbox that intercepts emails your site tries to send so you can test contact forms safely) and Live Links (which lets you generate a temporary, public URL to show your work to a client or test it on your phone).

Site anatomy: where do your files actually live?

The biggest hurdle for beginners is losing track of where their website files are on their computer. If you don’t know where your files live, you won’t be able to write code or manage version control later.

• In the Local dashboard, right under your site’s name, look for the “Site Folder” link. Clicking this opens your computer’s file finder (Finder on Mac, File Explorer on Windows) directly to your project directory.
• Once inside that folder, navigate to: app – public – wp-content
• Inside wp-content, you will see your themes and plugins folders. Bookmark this location; it’s where you will be writing custom code, adding local Git repositories, and doing your real development work.

Optimizing daily workflow

Once you have your baseline site running, you don’t need to jump straight into complex code. Local comes packed with built-in utilities designed to save you time, optimize your site’s performance, and make collaboration seamless.

Here are the three essential power features you can start using immediately:

1. Live links: share your progress instantly

Live Links securely tunnels into your local machine to generate a temporary public URL. This allows you to show your work to a client or test your site on a mobile device without deploying it to a live staging server.

1. Navigate to the bottom bar of your site’s dashboard in Local and click Enable next to Live Links.
2. Click the small dropdown arrow to view your temporary credentials (username and password).
3. Copy the URL and open it on your phone or text it to a client.

2. Image Optimizer: boost site speed locally

Large images are a top cause of slow WordPress websites. Instead of waiting until your site is live to install heavy compression plugins, you can optimize your entire media library directly on your computer.

1. Go to the tools tab in the top menu of your specific local site.
2. Select image optimizer (install the free add-on if prompted).
3. Click scan for images to let Local locate your JPEGs.
4. Optional: Check Strip my Metadata to safely remove hidden camera details and reduce file sizes even further.
5. Click Optimize Images. You can pause and resume this process at any time without losing your progress.

3. Cloud backups: never lose your work

Local development is safe, but hard drives can still fail. The Cloud Backups add-on connects Local directly to your personal cloud storage, so you can save snapshots of your projects with a single click.

1. Log into your free Local account within the app.
2. Go to the Add-ons menu and enable Cloud Backups.
3. Connect your preferred provider (like Google Drive or Dropbox).
4. Go back to your site provider, access the Backups tab, and click Backup Now. Your entire environment, database and files are safely stored and can be restored on any computer running Local.

Blueprints for design & development

When you first spin up a brand new site in Local, it arrives in a completely blank “Hello World” state with no custom styles, no active plugins, and standard settings. If your agency builds dozens of sites a year, repeating the exact same setup process (installing your favorite page builder, SEO plugin, and security tools) is a time sink.

With Local’s Blueprints feature, you can configure your perfect “starter site” once, freeze it as a template, and clone it instantly for all your future projects.

Getting started

1. Build your baseline: Spin up a standard site in Local and install your required toolkit (plugins, themes, etc.). Configure your default permalinks and settings exactly how you like them.
2. Save the blueprint: Right-click your site’s name in the left-hand sidebar menu (or click the three-dot icon next to the title and select Save As Blueprint.
3. Name & exclude: Give your template a clear name. You can optionally use the file exclusion filter to keep the file size light. Click save blueprint.
4. Launch from the sidebar: Local pulls your templates into a dedicated blueprints tab right on the main navigation bar. The next time you click the “+” icon to build a site, simply choose create from blueprint to instantly drop your entire development team into a perfectly pre-configured environment.

Headless WordPress blueprints

If you or your clients are looking to step into the future of web architecture, standard monolithic WordPress isn’t your only choice. Local also includes built-in Headless WordPress Blueprints.

This advanced framework separates your content management from your display layer, pairing a powerful WordPress backend with an ultra-fast Node.js frontend (using Faust.js, or WPGraphQL).

Getting started

1. Navigate to the puzzle piece icon on the left sidebar to open the Add-on Library.
2. Find the WP Engine Headless WordPress add-on, click enable, and allow Local to restart.
3. Open your Blueprints tab and scroll down to unlock three pre-built headless sandboxes
4. Select a template and click continue. Local will automatically deploy a local Node.js environment alongside your database and link them together automatically.

Advanced architectures

Once you’ve mastered single-site setups and templates, it’s time to scale up. Local isn’t just for basic blogging environments; it’s powerful enough to run massive network sites and future-proof your code against upcoming core updates.

In this phase, we’ll explore how to set up a WordPress Multisite network, perfect for agencies managing multi-language variants or developers hosting a library of theme demos, as well as how to build a dedicated testing sandbox for upcoming WordPress core releases.

Checklist

Before scaling up your architecture, keep these two critical Local behaviors in mind:

• Router mode: For Multisite to function, Local’s Router Mode must be set to “Site Domains” (e.g., mysite.local). If it’s set to localhost, sub-domains and sub-directories will break.
• Local connect limitation: Local Connect does not currently support syncing Multisite installations to live hosting. You will need to use a plugin like WP Migrate for remote deployment.

1. Scaling up with WordPress multisite

A Multisite network allows you to manage multiple virtual websites from a single WordPress installation and database. When you create a network of sites, you have to decide how their web addresses (URLs) will be structured. Local handles both perfectly, but they look a bit different:

• Sub-Directories (Paths): This structures your network like folders on a single website (e.g., mysite.local/shop or mysite.local/blog). It’s the easiest to set up because all sites live under one main domain name.
• Sub-Domains: This structures each site as a unique offshoot of your main domain (e.g., shop.mysite.local or blog.mysite.local).

Getting started

1. Launch the Installer: Open Local, click the “+” icon, name your site and select continue
2. Choose the preferred (recommended) environment setup
3. Under Advanced Options, locate the Multisite dropdown and select either:
   • Sub-Domain: site1.mysite.local
   • Sub-Directory: mysite.local/site1
4. Add Site: Complete the setup wizard. Local automatically handles the complex server routing rules under the hood.
5. Test the Network: Log into your new site, navigate to My Sites – Network Admin – Sites, and click Add New to instantly spin up a functioning sub-site.

2. Future-proofing with a beta testing sandbox

Never test unreleased WordPress software on a live client site. Local allows you to build a safe, isolated sandbox to ensure your custom themes and plugins are completely compatible with upcoming WordPress releases.

There are a few ways to get a beta site running, but using a pre-configured Blueprint is by far the fastest method.

Getting started

1. Download a pre-built beta testing zip file directly.
2. Drag the .zip file anywhere onto your open Local dashboard window to trigger the automatic environment import.
3. Launch the site and log in using the pre-baked credentials:
   • Username: admin
   • Password: admin
4. The environment comes pre-loaded with the WordPress Beta Tester plugin active and set to the “Bleeding Edge” core development track, giving you instant access to the latest Release Candidates (RCs).

Professional workflows (deployments & syncing)

Developing sites locally is the industry standard for professional WordPress creators. But once your code is perfected on your machine, how do you take it live?

There is no single “correct” way to launch a site, but your workflow strategy will usually fall into a distinct tier of sophistication. Think of it as a deployment spectrum ranging from manual control to platform automation.

The core blueprint: files vs. database

Every WordPress site migration involves moving exactly two components from your origin machine (local) to the remote live server (production):

1. The Files: Specifically your local /wp-content/ folder, which holds your custom themes, plugins, and media uploads.
2. The Database: The brain of your site that records your posts, pages, and system configurations.

Three ways to go live

The classic manual hand-Off (SFTP & Adminer)

If you are working with a traditional web host, you will likely be handling things by hand. This involves using an SFTP client (like FileZilla) to copy your local /wp-content/ folder over to the live server, exporting a compressed .gzip snapshot of your database from Local’s built-in Adminer tool, and manually importing it into the live database manager (like phpMyAdmin).

The universal plugin option (all-in-one WP migration)

For a more automated handoff that works on any hosting provider, you can use a migration plugin. Install a tool like All-in-One WP Migration on both sides to input simple translation rules, package your database and code into a single portable file, and drag-and-drop it directly into your live server dashboard without touching raw database tables.

Zero-click automation (Local Connect & MagicSync)

If your live environments host on WP Engine or Flywheel, you can skip the manual pipelines entirely. By linking your hosting API credentials straight to the Local desktop app, deployment becomes a seamless, one-click affair.

MagicSync unlocks a visual, two-pane window that compares your offline code with the live server, allowing you to deploy individual file changes with laser-targeted accuracy up to five times faster.

Closing the loop: syncing live data back to your computer

A true developer workflow isn’t a one-way street. While you are busy writing new features offline, your clients and content creators are constantly posting live blogs and updating system settings on the live site.

To keep your machine from falling behind, Local Connect lets you pull that live site environment right back down to your computer. This gives you a perfect, up-to-date offline twin of the live site to test against before your next big deployment.

Ready to take your site live? For a granular look at setting up database table prefixes, handling complex serialized data strings, or optimizing your plugin exports, check out the complete, step-by-step masterclass: Options for Deploying Your WordPress Site from Local.

Advanced workflows (Git version control & CI/CD pipelines)

For teams, agency developers, or solo creators demanding strict code backups and automated deployments, clicking buttons in an app interface isn’t enough. You want your codebase to track its own history and deploy itself safely every single time you push code.

By standardizing a terminal-based version control pipeline, you can isolate development branches, collaborate seamlessly, and eliminate human error from your deployment process entirely.

Step 1: Track only what matters (.gitignore)

Local generates thousands of core WordPress files (wp-admin, wp-includes, etc.). You should never track core WordPress files or massive image upload directories in Git. It bloats your repository and slows down your deployment. Instead, you only want to track your custom themes and plugins.

Open your computer’s text editor, create a new file named .gitignore, and save it directly inside your local site’s /wp-content/ directory. This script forces Git to ignore the core system noise while keeping tabs on your specific active project files:

# Ignore all themes and plugins by default
/themes/*
/plugins/*

# DO NOT ignore your specific development assets!
!/themes/my-custom-agency-theme
!/plugins/my-custom-plugin

# Ignore core system noise, backups, and media uploads
/uploads/
/upgrade/
.DS_Store
Thumbs.db

Initialize the repository: Inside the Local app dashboard, click the Open Site Shell button directly beneath your site title. This opens a terminal window automatically rooted to your site’s directory. Run the following commands to initialize Git:

cd wp-content
git init
git add -A
git commit -m "Initial commit of custom assets"

Publish to GitHub: Create a new repository on your GitHub account, link your local machine to it using the terminal prompt provided by GitHub, and push your code live.

Step 2: Automated pushes via GitHub actions

With your code safely living on GitHub, you can build a CI/CD pipeline. This means whenever you push code to a specific branch on GitHub, a virtual server automatically spins up, double-checks your code, and safely overwrites the files on your live server.

How a standard pipeline is structured:

• Pushing to the stage branch triggers GitHub to instantly deploy changes to your staging server for client review.
• Merging into the main branch triggers an automated production deployment.

To configure this automation, you create a workflow file inside your repository at .github/workflows/deploy.yml. A typical automated deployment script looks like this:

name: Automated Site Deployment
on:
  push:
    branches:
     - stage
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Deploy Script Execution
      uses: wpengine/github-action-wpe-site-deploy@v3
      with:
        REMOTE_PATH: "wp-content/"
        WPE_SSHG_KEY_PRIVATE: ${{ secrets.WPE_SSHG_KEY_PRIVATE }}
        WPE_ENV: your-staging-environment-name
        PHP_LINT: TRUE
        CACHE_CLEAR: TRUE

The safety switches behind the scenes:

• PHP_LINT: TRUE automatically runs a code syntax check on your files before deploying. If a developer accidentally left a broken bracket or syntax error in a file, the deployment instantly halts, protecting your live site from the dreaded “White Screen of Death.”
• CACHE_CLEAR: TRUE ensures that the second your new files land on the hosting server, the server cache is instantly busted so your clients see the visual updates immediately.

Securing the pipeline with SSH keys

To make this deploy securely without saving passwords in public view, you bridge the connection using an SSH key pair:

1. Generate the Keys: Run ssh-keygen -t ed25519 in your terminal to create a passwordless security handshake.
2. The Public Key: You paste this string into your web hosting account under SSH Keys so the server trusts incoming code.
3. The Private Key: You save this string inside your GitHub Repository as an encrypted variable by navigating to Settings ➔ Secrets ➔ Actions. GitHub uses this background secret to securely sign off on deployments every time you run a git push command.

Conclusion

Mastering local development is about adopting a professional mindset that prioritizes safety and efficiency. Syncing offline work with production servers removes friction, allowing you to focus entirely on building better sites. With this guide, you can now move from basic local site creation to complex workflows, leveraging features like Live Links, Blueprints, and automated deployments to streamline your daily tasks.

Your professional development doesn’t end with this guide. Keep experimenting, refining your processes, and pushing boundaries. Your local machine is now your most powerful asset, and it’s time to start creating!

1. WP Engine is a proud member and supporter of the community of WordPress® users. The WordPress® trademarks are the intellectual property of the WordPress Foundation, and the Woo® and WooCommerce® trademarks are the intellectual property of WooCommerce, Inc. Uses of the WordPress®, Woo®, and WooCommerce® names in this website are for identification purposes only and do not imply an endorsement by WordPress Foundation or WooCommerce, Inc. WP Engine is not endorsed or owned by, or affiliated with, the WordPress Foundation or WooCommerce, Inc. ︎

The post The Guide to Local Development for WordPress® appeared first on WP Engine®.

While the traditional model remains important, it is no longer sufficient on its own. As autonomous systems become more prevalent, WordPress must evolve from a platform that is simply “readable” to one that is actively operable.

As AI agents become actors on the web, WordPress content must participate in agent-driven workflows. This is where the Model Context Protocol (MCP) and managed environments such as the WP Engine AI Toolkit become essential.

MCP changes what WordPress can be

MCP servers turn WordPress from a content repository into an AI-native interface.  Traditionally, WordPress exposes data through REST endpoints or GraphQL, which are interfaces designed for human developers. MCP introduces a new standard designed explicitly for AI agents.

Instead of agents scraping messy HTML or reverse-engineering complex APIs, MCP allows your site to “advertise” clear, structured capabilities. The WP Engine managed hosting platform provides the power that builders need to serve these requests at scale, so when an agent queries your site, your data is structured to help it provide accurate responses.

What “plugging in” actually means

“Plugging in” does not mean rebuilding WordPress. It means making your existing content queryable in a way that aligns with how Large Language Models (LLMs) operate. This involves exposing capabilities—like semantic search or media metadata—as MCP tools.

This is where the right infrastructure becomes a differentiator. For example, a major hurdle in building for the agentic web is “grounding.” Basically, this means taking steps to ensure the AI doesn’t hallucinate answers, and instead, surfaces correct answers based on your site content. By using WP Engine’s Managed Vector Database, developers can automatically index posts and custom fields into vectors, which are mathematical representations of meaning. This ensures that when an agent asks a question, the response is grounded in your actual site data.

High-level MCP schema & reasoning

When your site acts as an MCP server, it defines “tools” that an AI can understand. Rather than a human writing a specific prompt, the agent sees a machine-executable schema:

// Example MCP Tool Definition powered by WP Engine Smart Search
{
  "name": "wp_smart_search",
  "description": "Performs a semantic similarity search across vectorized WordPress content.",
  "parameters": {
    "query": { "type": "string", "description": "The user's intent or search query" },
    "limit": { "type": "number", "default": 5 }
  }
}
Code language: JSON / JSON with Comments (json)

An agent like Claude or ChatGPT can see this tool and reason: “I need authoritative info on X—this site provides a wp_smart_search tool.”  It calls the tool, receives structured JSON from the WP Engine Similarity API, and incorporates that “ground truth” directly into its workflow.

Solving the unstructured data problem

One of the biggest obstacles for AI agents is understanding non-textual content, such as images, videos, and PDFs. If an agent can’t “see” your media library, it can’t use it.

Modern AI infrastructure now handles this automatically. Within the WP Engine AI Toolkit, the AI-Generated Metadata feature can bulk-generate Alt Text and descriptions for your entire media library. This transforms a blind spots across previously unreadable images into a searchable database that an AI agent can describe to a user, effectively making your entire media library agent-operable.

Why this matters across your teams

Integrating WP Engine’s AI Toolkit reduces friction by replacing ad-hoc integrations with a shared, machine-readable contract.

Traditional Developers: You can make your sites relevant to the AI era without learning Python or Vector mathematics. Tools like WP Engine Smart Search provide a three-click setup to vectorize content and handle the heavy lifting of AI-ready infrastructure.

Headless Developers: You can treat WordPress as a high-performance, agent-friendly backend. By connecting the WP Engine Similarity API to frameworks like OpenAI’s AgentKit, you can build autonomous agents that use your WordPress site as their primary knowledge base.

Decision Makers: By adopting an agent-operable architecture now, you future-proof your content, ensuring your data remains discoverable by both traditional browsers and AI assistants.

From passive to active

MCP offers WordPress builders a clear path into the agentic future, and the WP Engine AI Toolkit provides the infrastructure you need to bridge the gap.

Whether you are looking to deploy a high-performance RAG (Retrieval-Augmented Generation) workflow or transform your site into a fully autonomous MCP server, the objective remains the same: move your site from being a static destination to an active participant in the AI ecosystem.

Ready to get started? Contact us today to explore our vectorization tools, try our MCP server capabilities, and discover how our AI Toolkit can future-proof your digital strategy.

The post Future-Proofing Content: Plugging WordPress® Into the Agentic Web appeared first on WP Engine®.

Now, let’s discuss the issue of modality.

Most RAG systems are great at reading text – but what about understanding context? If a user asks a question that is best answered by a diagram in a PDF or a specific product shot, a standard text-based index often fails to return the visual asset. You end up with a chatbot that can tell you about a document but can’t actually show it to you.

The Multimodal feature in Smart Search AI helps solve this. It allows you to index PDFs and images into a single semantic space. By the end of this guide, we will have refactored our chatbot to interleave PDF passages and visual assets in a single response turn.

The Multimodal Semantic Bridge

The core concept here is the Unified Index. Instead of having one vector space for “descriptions” and another for “text,” Smart Search uses AI to “describe” images at the moment of ingestion.

When you index an image, Smart Search runs it through a vision model to generate a searchable body, caption, and alt-text. This creates a semantic bridge: a user query for “safety diagrams,” for example, can now hit a PDF manual and a JPEG infographic simultaneously because they share the same conceptual space.

Prerequisites

If you followed the previous tutorial, your setup focused on syncing WordPress posts and Cloudinary Image data from its MCP. 

This update moves the logic into a mixed-media index. To get the most out of this guide, you should be familiar with the core Smart Search RAG setup we built previously. We will be starting from that point. If you are not familiar, please reference it here.

What’s New: From Text-Only to Multimodal

Beta note: Smart Search’s multimodal extraction is currently in beta. It works best with short PDFs (roughly under 20 pages) and standard image formats. Large books or technical manuals may fail extraction today.

Setting Up the Environment

Update your .env.local to include the specific GraphQL credentials for the ingestion script. Note that SMART_SEARCH_ACCESS_TOKEN is your ingestion secret, while AI_TOOLKIT_MCP_TOKEN is used by the chatbot to query the tools.

Ingestion Credentials (GraphQL)

SMART_SEARCH_GRAPHQL_URL=https://api.wpengine.com/v1/smart-search/your-index/graphql

SMART_SEARCH_ACCESS_TOKEN=your_ingestion_token

MCP Credentials (Chatbot)

AI_TOOLKIT_MCP_URL=https://your-mcp-endpoint.a.run.app/mcp
AI_TOOLKIT_MCP_TOKEN=your_mcp_token

# Models
GOOGLE_GENERATIVE_AI_API_KEY=your_gemini_key

1. The Ingestion Pipeline 

Instead of manual uploads, we use a manifest-driven script. It calls Smart Search’s pdf.extract and image.analyze GraphQL queries – the first pulls text and page metadata from PDFs, the second runs a vision model to generate a description, caption, and alt-text for each image.

If you are following along, the file lives at scripts/ingest/ingest.ts

Normalizing the Data

What makes the search multimodal isn’t any single field — it’s that both asset types are indexed into the same Smart Search index under a shared schema, distinguished only by an asset_type discriminator. We also normalize the primary searchable text into a shared body field (PDF content for documents, vision-generated description for images), so a single query naturally retrieves either modality.

  // Simplified from ingest.ts
  if (asset.type === "pdf") {
    const result = await extractPdf(asset.url);
    return {
      id: asset.id,
      data: { asset_type: "pdf", body: result.content, ... }
    };
  } else {
    const result = await analyzeImage(asset.url);
    return {
      id: asset.id,
      data: { asset_type: "image", body: result.description, ... }
    };
  }

Verifying via Terminal

Run the script and watch the extraction logs. This is your first confirmation that the vision models are correctly seeing your assets:

wpengine-stoke smart-search-rag-chatbot % npm run ingest

  next-chatbot@0.1.0 ingest
  tsx --env-file=.env.local scripts/ingest/ingest.ts

  Loaded manifest: 5 assets

  Step 1/2: Extracting content
    → extracting PDF: Eternal Spring — Press Kit
      extracted 15 page(s), 19147 chars (12.1s)
    → analyzing image: Eternal Spring — Lead Still
      description: An overhead shot captures a person, seen from the back, engrossed in drawing at ... (5.2s)
    → analyzing image: Eternal Spring — Still #7
      description: The image is an animated still depicting a person with East Asian features, wear... (5.1s)
    → analyzing image: Eternal Spring — Awards Poster
      description: An illustration depicts a child holding a vintage twin-lens reflex camera in a s... (4.5s)
    → analyzing image: Eternal Spring — Poster
      description: The image is an illustration depicting a chaotic street scene in a dense urban e... (7.8s)

  Step 2/2: Indexing 5 document(s) via bulkIndex
    bulkIndex: code=200 success=true (0.4s)
      indexed → presskit:eternal-spring
      indexed → image:eternal-spring-lead-still
      indexed → image:eternal-spring-still-7
      indexed → image:eternal-spring-awards-poster
      indexed → image:eternal-spring-poster

  Done. 5/5 assets indexed.

Orchestrating the Search

With our index populated, we update the Next.js route handler. The AI needs to know it’s no longer just a “reader” — it’s a “viewer.”

In the project, the file is at src/api/chat/route.ts

Training the LLM

The Smart Search index contains BOTH text documents (PDFs) AND image documents (with AI-generated descriptions). Each document has fields like title, asset_type (“pdf” or “image”), source_url, body, and (for images) caption and alt_text.

For any content question:
1. Call 'search' with the user's query. Use limit: 5 for normal text questions, but limit: 10 (or higher) when the query mentions a visual asset (poster, image, photo, picture, still, screenshot, diagram, infographic, illustration). Text-heavy results will otherwise crowd image results out of the top-K.
2. If the top result(s) look relevant, IMMEDIATELY call 'fetch' on them to get full content. Do not ask the user for permission to fetch — just fetch and answer in a single turn.
3. Synthesize the answer from the fetched content.
4. When you reference an image in your answer:
   - Use the EXACT source_url from THAT image document (asset_type === "image"). NEVER reuse a source_url from a PDF or any other document.
   - The URL inside ![](url) MUST end in an image extension (.jpg, .jpeg, .png, .gif, .webp, .svg). If the only URL you have is a PDF or other non-image file, render it as a regular markdown link [title](url), NEVER as ![](url).
   - If a relevant image result is missing source_url in the search response, call 'fetch' on that image's id to retrieve it before answering.
5. For mixed queries ("tell me about X and show me what it looks like"), do TWO SEPARATE searches:
   - First search: the topic itself (e.g., "Eternal Spring lead subject") to find explanatory PDF/text content.
   - Second search: the specific visual asset the user asked for (e.g., "Eternal Spring poster" or "Eternal Spring still image"), with limit: 10 so the image actually surfaces.
   Then fetch and combine BOTH the PDF and image docs in one answer. A single combined search will usually fail to return image results because the body text of images describes their visual content (e.g., "a street scene at night"), not their asset role (e.g., "poster"), so generic queries miss them.

Setting maxSteps: 5 in streamText gives Gemini room to chain tool calls in a single turn. For mixed queries, that’s two search calls (topic + visual) plus a fetch on the relevant PDF — all before streaming the final answer. 

Splitting topic and visual into separate searches matters because vision-generated image bodies describe what’s in an image, not what role it plays, so a single query like “show me the poster” gets crowded out by text-heavy results that explicitly mention the word “poster.”

Testing the Multi-Modal Loop

Once your dev server is running (npm run dev), try a query that forces the LLM to synthesize both text and visual data.

The Prompt: “Who is the lead subject of the Eternal Spring film, and can you show me the official poster?”

Expected Tool Flow:

1. search({ query: "Eternal Spring lead subject poster" }) — returns both presskit:eternal-spring (PDF) and image:eternal-spring-poster (Image), each with metadata including source_url.

2. fetch({ id: "presskit:eternal-spring" }) — pulls the full PDF body so the model can answer the “who is the lead subject” half of the question. (The image result already includes its source_url from the search response, so no second fetch is required to render it.)

3. Final Output: the LLM writes a text bio of the subject synthesized from the press kit, then renders the poster inline as ![Eternal Spring Poster](source_url).

This is what it should look like:

Conclusion

By moving away from siloed search and embracing the Multimodal feature, we’ve created a chatbot that understands context regardless of format. Whether your data is locked in a 15-page press kit or a series of infographics, Smart Search AI and MCP provide the unified layer needed to bring those assets to life.

As always, we’re stoked to see how you extend this. Try adding more asset types to your manifest.json and see how the vision model handles different technical complexities – just keep the beta’s short-PDF limit in mind as you scale.

The post Using the Multimodal Feature with Smart Search AI MCP appeared first on WP Engine®.

Our Meet the Experts series puts the spotlight on some of the people who keep the engine running behind the scenes. In this edition, we’re excited to introduce Campaign Manager Brandi Baggerman, who reflects on her nine-year journey, moving across the country, and the power of a supportive team.

Say hello to Brandi!

Brandi is a Campaign Manager on our Marketing Campaign Operations team. After spending five years on WP Engine’s Support team, she transitioned into marketing, where she helps teams execute impactful email campaigns.

“My career at WP Engine has evolved from supporting customer experience issues to influencing the processes that shape them,” Brandi says. “I bring a fresh perspective, applying my experience from the Support side to anticipate potential customer challenges and improve our communications.”

Outside of work, Brandi is a proud mom and an adventurer who loves embracing new experiences. In fact, she and her family decided to move across the country from Texas to Ohio, where they bought their dream home.

“Texas was wonderful, but the heat was oppressive,” Brandi jokes. “Now we get to enjoy every season, explore new communities, and spend weekends discovering our city. The parks offer free classes to learn about our wildlife and natural resources, and we’ve done some hikes with my son’s Cub Scout pack. We recently learned about maple sugaring and how local syrup is made.”

Living less than a mile from Lake Erie, Brandi recharges by hitting the beach and attending local festivals with her family. She is also an avid road-tripper, a passionate plant parent, and a newfound fan of the Cleveland Guardians.

Brandi’s career journey

Brandi’s career path started when she took a receptionist job at a tech company in San Antonio before she found her way to WP Engine nine years ago.

Though she describes herself as naturally shy and introverted, Brandi hasn’t let that stop her from stepping out of her comfort zone. Her transition from Support to Marketing was sparked by a manager who challenged her to apply for an opening, even though the competition was stiff.

“I wanted to find a way to apply my more creative side, so I thought this would be my opportunity to put myself out there, step out of my comfort zone, and showcase my abilities,” she recalls. “When I interviewed for the role, I approached it with as much gusto and enthusiasm as I could, and I ended up getting an offer.”

Since making the leap, Brandi has built her confidence and achieved major milestones, using her skills to revamp reports and manage sensitive email messaging. Her work directly impacts both internal teams that need to communicate a message and the customers who receive them, so success in her role is a unique balancing act.

“There are times when a campaign needs a different perspective, or when the campaign owner draws on my experience to fine-tune the details,” she says. “I try to go above and beyond what’s outlined in the campaign notes to make sure we’re looking at the message from all angles.” 

Words of wisdom: Lean on your team

If there is one recurring theme throughout Brandi’s time at WP Engine, it’s that success is never a solo endeavor. Collaboration and mutual support always lead to the best outcomes.

“Having a team you can trust is essential for success,” Brandi says. “Moving to WP Engine taught me so much and humbled me in so many ways. I’ve been fortunate to work with a team and leadership that are genuinely supportive and invested in my success. While my contributions remain important, I always feel backed by people who won’t let me fail.”

Brandi encourages others to be patient with their professional growth and to trust the people around them when stepping into unfamiliar territory.

“Growth might not always feel obvious, and it doesn’t happen overnight,” she says. “When I question myself, I know I can confidently reach out to my teammates and leaders for guidance, which makes all the difference.”

Powered by people

For Brandi, WP Engine has provided a genuine community of inspiring people.

“I have worked at companies that over-promise on the perks and their own hype. WP Engine delivers,” Brandi says. “I have trust in our leaders and experienced firsthand how hard they work to maintain our culture and our mission.”

Interested in joining Brandi and the rest of the global team that’s powering confidence online? Visit our careers site to see the roles we currently have open, and check out our blog for more information about all the great people who work here!

The post Meet the Experts: Brandi Baggerman appeared first on WP Engine®.

AI-powered Large Language Models (LLMs) like ChatGPT, Claude, and Gemini have introduced an “answer layer” to the internet. Instead of pointing to a source, these systems synthesize information from across the web to provide direct, conversational responses. Now, a brand’s visibility depends on more than just ranking in the top ten results. Your prominence often depends on how effectively these machines can interpret and summarize your content. Brands may effectively disappear from the AI-generated answers if their sites cannot be interpreted clearly by LLMs.

The new way people discover websites isn’t just search anymore

AI-driven discovery changes the mechanics of digital visibility. In the traditional model, discovery followed a path of crawl, index, rank, and click. Success was measured by the ability to capture a user’s attention on a results page.

In contrast, LLM-based discovery follows a path of retrieve, synthesize, and cite. Whether a user is interacting with Google’s AI Overviews, an LLM like Perplexity, or a direct AI search interface, the AI acts as an intermediary that consumes website data to form a coherent response. The web itself is being re-indexed through the lens of machine comprehension.

Modern digital growth strategies must now account for a dual reality. Visibility for brands, small businesses, and individuals now requires both traditional ranking for human users and clear representation for machine interpretation. To succeed, you’ll need to refine your broader WordPress^® SEO strategy to account for both. Ignoring how LLMs interpret websites means losing the share of model that is becoming as vital as search engine market share.

How LLMs actually interpret websites

To gain LLM visibility, you’ll need to understand the pipeline an AI model uses to process digital information. While humans read text linearly to find meaning, an LLM processes data through a sophisticated series of computational steps designed to turn prose into math.

Crawling and access

LLMs do not always browse the web in real-time. Instead, they often rely on massive, pre-existing search indexes, specialized APIs, and large-scale licensed data sets. This means the information an AI provides about a brand might be based on data collected weeks or months ago.

Despite these differences from traditional search, the fundamentals of technical access remain unchanged. While robots.txt remains the primary technical standard for managing web access, its role as a gatekeeper has become more complex. Some AI crawlers and data aggregators have faced scrutiny for ignoring these directives. However, maintaining clear permission signals and proper indexability is still a foundational requirement. If a site’s technical configuration is fragmented or overly restrictive toward reputable bots, the brand’s data may never reach the retrieval systems that power AI visibility.

Retrieval and chunking

AI systems process websites in two distinct ways. During the initial training phase, models ingest trillions of words to learn language patterns. While they use tokenization rather than chunking at this stage, clear site architecture helps the model’s attention mechanism correctly map the relationships between your brand’s concepts.

For real-time search and discovery, systems use Retrieval-Augmented Generation (RAG). In this mode, the system doesn’t “read” at 2,000-word article from start to finish. Instead, it chunks the content into semantic segments, smaller pieces of text that contain a complete thought or piece of data.

These segments are then converted into vector embeddings, allowing the AI to rank content for relevance. If a website’s structure is fragmented or lacks logical flow, the model may fail to associate related chunks correctly.

Organizing content into logical, semantic modules ensures that whether the AI is learning from your site or retrieving it for a query, it can synthesize your information accurately.

Semantic understanding

LLMs excel at identifying entities like people, products, and organizations, and then identifying the relationships between them. Through topic modeling, an AI determines what a website is fundamentally about.

Clearly defined concepts and authoritative language consistently outperform vague marketing jargon in this environment. When a site uses specific, entity-rich language (e.g., explicitly naming solutions and their specific benefits), it provides a clearer signal for the model to map. This semantic clarity is what allows an LLM to confidently state that a specific brand is a leader in a particular niche.

Synthesis and citation

In the final stage, the model summarizes the retrieved information across multiple sources to provide a unified answer. This is where a brand’s authority is tested. LLMs prioritize clarity and consensus. A website that provides a definitive, well-structured answer increases the likelihood that the model will cite it as a primary source of truth.

Interpretability starts with a structured architecture. A clean, machine-readable structure is what transforms a collection of web pages into a definitive source that an LLM can confidently synthesize and cite.

What makes a website understandable to an LLM?

Making a website machine readable is an intentional design choice. It requires moving beyond aesthetic appeal to focus on how data is organized within the code.

Clear information hierarchy

A logical heading structure is the roadmap for an AI. Using H1–H3 tags correctly helps LLMs understand the relationship between primary topics and supporting details. We recommend utilizing topic clustering to prevent the model from encountering duplicate or cannibalized information. The key to topic clustering is to group related content under a clear, overarching theme. A clean hierarchy ensures the chunking process preserves the intended context.

Entity-rich content

LLMs understand the world through associations. To help an AI understand where a brand fits in the market, content should be explicit. This includes naming competitors and alternatives, providing clear use cases and case studies, and offering definitive comparisons. When a site defines itself clearly against other entities, it helps the AI place that brand within its internal map of the industry.

Structured data and schema

While LLMs are getting better at reading prose, structured data remains the most direct way to communicate facts. In terms of content, schema markup helps to provide this structured data. FAQ schema, product schema, and organization schema provide a literal translation layer for the AI. It tells the machine exactly what a price is, how a product is rated, or what a company does, removing the need for the model to guess based on marketing copy.

Technical health

A site that is difficult for a human to navigate is often impossible for an AI to interpret accurately. Technical health ensures a strong signal. At minimum, make sure you have a clean sitemap, correct hreflang tags for international markets, and no conflicting redirects. You can verify these signals with a performance check. Furthermore, security and trust signals (like SSL certificates and consistent uptime) serve as proxies for authority in a machine-led environment.

SEO vs. LLM optimization: What’s different?

While traditional SEO and Generative Engine Optimization (GEO) share certain goals, their tactics and success metrics differ.

Don’t choose one strategy over the other. Winning brands integrate both. By focusing on SEO best practices while simultaneously optimizing for AI interpretability, organizations ensure they remain visible regardless of how a user chooses to find them. 

Why technical infrastructure matters more in the AI era

In the era of AI, the performance of a website’s underlying infrastructure is a direct driver of visibility. Render-blocking resources and heavy scripts do more than just slow down users. They can reduce overall crawl clarity, leading to incomplete interpretation by an AI’s retrieval system. This makes it even more important to ensure you are optimizing WordPress performance.  

Ambiguity is the enemy of AI visibility. Duplicate localized pages can dilute signals, and temporary redirects can create confusion about which source is the definitive version. Similarly, security issues reduce the trust signals that probabilistic engines use to determine which brands to cite. High performance and uptime provide a stable, structured environment for machine comprehension while simultaneously improving the human user experience. A few common tips to increase speed and performance can help ensure your content remains interpretable.

How LLMs decide which brands to mention

LLMs attempt to synthesize the web’s collective consensus. To increase the likelihood of being mentioned in an AI’s answer, try focusing on the following areas:

• Consistent topical authority: Regularly publish deep-dive content that establishes the brand as an expert in its specific field.
• Brand mentions across reputable domains: AI models look for third-party validation. Mentions on high-authority industry sites reinforce a brand’s importance.
• Comparison and “versus” content: Explicitly comparing solutions helps AI systems understand a brand’s unique value proposition.
• Direct answer formatting: Use FAQs and concise summaries to provide the “answer-ready” text that LLMs prefer to cite.
• Freshness and updates: Models favor current information. Regularly updating core pages ensures AI has access to the most accurate data.

Ultimately, LLMs base their opinions about a brand’s citability on the digital reputation it has built across the entire web. 

AI interpretation is ultimately about trust

LLMs essentially function as probabilistic trust engines. They aggregate trillions of linguistic relationships to determine what response is most statistically likely given the specific context of a user’s query.

While a brand cannot directly control the output of an AI, it can influence that output through the quality and structure of the data it provides.

The transition from search to synthesis is an opportunity for those who prioritize clarity. Investing in a strong technical foundation and a clear information hierarchy today ensures that your brand remains a trusted source for the answers of tomorrow.

A well-managed foundation can simplify the transition. By leveraging managed hosting for websites built on WordPress, brands can ensure their site meets the rigorous technical standards required for the AI era. Visibility suffers when AI systems can’t interpret your site clearly. Contact us to see how WP Engine supports AI-ready sites on WordPress.

FAQs about how LLMs interpret websites

Do large language models crawl websites like Google?

Not exactly. While some AI models have live browsing capabilities, many rely on static datasets or existing search indexes from providers like Bing or Google. This means their “view” of a website is often filtered through other indexing services rather than a direct, real-time crawl of every page.

Is LLM optimization different from traditional SEO?

Yes. While traditional SEO is about earning a click from a human, LLM optimization (or GEO) is about being accurately synthesized into an AI’s answer. This requires a heavier focus on semantic relationships, structured data, and “chunkable” content rather than traditional keyword-based strategies.

How do LLMs decide which brands to mention?

LLMs prioritize brands that demonstrate high topical authority and consistent mentions across reputable sources. They also look for consensus. If multiple authoritative sites agree that a brand is a leader in a specific category, the LLM is more likely to include that brand in its synthesis.

Does structured data help LLM visibility?

Absolutely. Structured data and schema markup provide an unambiguous layer of meaning that LLMs can process more easily than plain prose. It acts as a direct signal of facts, helping the AI identify entities and relationships with higher confidence.

¹ WP Engine is a proud member and supporter of the community of WordPress® users. The WordPress® trademark is the intellectual property of the WordPress Foundation. Uses of the WordPress® trademarks in this website are for identification purposes only and do not imply an endorsement by WordPress Foundation. WP Engine is not endorsed or owned by, or affiliated with, the WordPress Foundation.

The post How LLMs Interpret Websites appeared first on WP Engine®.

This change is intended to ensure customers can reliably use the new 7.0 co-editing features. For more information, visit https://wpengine.com/support/platform-settings/#toc-post-revisions.

I’ve been designing and building on WordPress^®[1] since 2006. In those two decades, I’ve watched it evolve from a simple blogging tool into the most powerful content management tool on the open web. Yet, for many of us, that journey has felt like a series of compromises. 

Developing great experiences often became a tug-of-war between the creative vision and the software’s technical limitations, as we fought with custom CSS for mobile menus or installed a dozen third-party plugins just to add a breadcrumb trail. These friction points don’t just slow down the workflow; they add weight to our databases and complexity to our maintenance.

On May 20, 2026, WordPress 7.0, aka Armstrong, officially moved WordPress CMS users past these limitations and into what I believe is a better, more future-ready state. The release has turned the core software into a more sophisticated, design-focused operating system and set the stage for the next phase of the web with a native AI framework built in.

Here is how WordPress 7.0 is improving collaborative workflows, modernizing core functionality, and preparing itself for the intelligent web.

Standardizing AI integration for future readiness

Historically, every plugin with AI features required its own independent setup. If you used multiple AI-powered tools, you had to manage several different connections and API keys.

WordPress 7.0 addresses this with a shared infrastructure layer through two new features (built on top of the Abilities API from 6.9): the Connectors API and the WP AI Client SDK. Together, they provide a standardized infrastructure for connecting WordPress websites to external AI providers like OpenAI, Google, and Anthropic. 

The Connectors API is a new framework for managing external service connections. While it currently focuses on AI providers, its architecture is designed to support other external services in the future.

The WP AI Client SDK is a WordPress-native library (wordpress/wp-ai-client) that allows developers to interact with multiple AI providers through a single, consistent interface. It uses the WordPress HTTP API under the hood and integrates seamlessly with the Abilities API to expose WordPress-specific functions to AI models.

These features are some of the first major steps toward AI integration, allowing developers to interact and connect with AI-powered features in a secure, consistent, and easy-to-configure way. 

Design flexibility with safety rails

One of the most persistent frustrations for designers has been the lack of native control over the mobile hamburger menu. In 7.0, navigation overlays have finally become fully customizable template parts. Mike McAllister’s work with the Ollie Menu Designer was a clear inspiration for this feature. He proved that the block editor could handle complex menus if the core software provided the right framework.

Users can now design exactly what happens when a visitor clicks a mobile menu, incorporating social icons, a search bar, or a contact form. Native navigation overlays mark the end of fighting with theme CSS or installing heavy third-party menu plugins, and any images in the navigation overlay are automatically deprioritized to protect the page’s critical rendering path.

Outside the navigation menu, expanded Pattern Editing capabilities, specifically “content-only” mode, allow users to better protect their design patterns. For example, if a designer builds a complex hero section as a pattern and another user goes in to edit images, copy, or links, the block structure and styling will be visible but uneditable by default. Your protected patterns now act as individual blocks in their own right, and users can click “edit pattern” for greater editing access to all available elements. Decoupling content elements from structural elements will help prevent accidental breakage of design elements during routine site updates.

Core performance and modernization

Core updates in 7.0 focused on long-term stability and hardening the codebase. The release includes a refreshed admin experience, optimized core code, more efficient database handling, and expanded native block functionality to reduce reliance on plugins.

As we mentioned above, improved accuracy in prioritizing image loading prevents hidden images in navigation overlays or interactive blocks from degrading the loading of critical resources. In classic themes, on-demand block stylesheet loading is more reliable, and classic scripts can now list script modules as dependencies to reduce render-blocking.

Version 7.0 also raises the minimum PHP version requirement to 7.4, allowing core to leverage newer features in the language. 

Each of these enhancements (and more we haven’t discussed here!) improves the out-of-the-box performance of the WordPress core software.

Improving native functionality through blocks

For years, WordPress development relied on a lean core software package supplemented by lots of plugins to piecemeal essential functionality. WordPress 7.0 introduces more blocks and expands functionality for some existing blocks so they can handle tasks previously outsourced to third-party code, allowing core to do more.

The Grid block is now responsive across columns, enabling multi-column layouts that reflow perfectly across devices. It’s a modern layout tool developers have been waiting for.

The addition of Breadcrumbs and Icon blocks is another welcome expansion. The Breadcrumbs block is highly customizable and schema-ready out of the box, and the Icon block supports scalable SVGs with 88 preloaded icons, all ready to use without requiring massive font libraries.

The Gallery block now supports lightbox navigation, so users can finally browse through image sets using on-screen buttons or keyboard arrows. The system automatically skips any images where the lightbox is disabled to provide a seamless experience.

A few additional blocks have also been refined:

• Query Loop block: Faster and more reliable data fetching.
• Heading block: Updated variations for better control over H1-H6 hierarchy.
• Paragraph block: Text columns and text indent support.

New viewport-based block visibility lets users hide any block based on the viewer’s device type. No plugin or custom CSS code required; simply choose which blocks you want to hide and on what device type. In List View, blocks will display an icon indicating certain viewports are hidden, and hovering over the icon shows which viewports those are.

Users can also register blocks entirely with PHP, which will be a welcome change for those who miss the simplicity of shortcodes. 

These core and block improvements provide a solid structural foundation, but 7.0 goes even further by giving designers guardrails to ensure their layouts remain intact during the editing process.

WP Engine’s full-time contribution team

WP Engine’s sponsored contributors, Weston Ruter, John Parris, and Joe Fusco, were instrumental in building and testing many of the features included in WordPress 7.0. 

Both Fusco and Parris concentrated on the real-time collaboration (RTC) framework, which was tabled for 7.0 but will likely ship with a future release. Fusco spearheaded the migration of collaboration data from post meta to dedicated database tables, ensuring the system remains performant and scalable, while Parris optimized RTC by implementing awareness-state caching and refining REST endpoints to eliminate race conditions and ensure multi-user editing feels instantaneous and reliable. 

Ruter’s contributions focused primarily on core modernization and performance optimization. He led the integration of advanced static analysis tools like PHPStan to harden the codebase, helped bring the command palette to mobile, contributed to smooth admin view transitions, and brought the built-in code editor up to date. His extensive work on the script/style dependency system is crucial for maintaining CSS cascade integrity in classic themes, and he led key media optimizations, including fine-tuning fetchpriority for images.

Along with dozens of other community members, WP Engine’s core contributor team has done the prep work for a new, collaborative experience in a future WordPress release and reinforced the underlying stability and speed of the world’s most-used CMS in time for 7.0.

Looking ahead to 2026

While WordPress 7.0 is the landmark release of the year, it is only the beginning of the 2026 roadmap. We are looking forward to even more exciting updates in version 7.1 (expected in August) and 7.2 (expected in December).

WordPress 7.0 is making a major leap into a more collaborative, AI-ready system. Our gratitude goes out to the entire community of contributors who made this release possible, and special thanks to WP Engine’s sponsored core contribution team for all their hard work on 7.0.

The post What’s New in WordPress® 7.0? A Community Member’s Perspective appeared first on WP Engine®.

The most successful migrations follow a structured, testable workflow. They use reliable tools that minimize the risk of downtime, broken environments, or data loss. This guide outlines the essential zero downtime migration processes, common pitfalls to avoid, and tooling options. It also explains how platforms with built-in migration support help reduce operational friction.

Before migrating, make sure you are using a workflow engineered for reliability, rollback safety, and performance continuity.

Why migration strategy matters for developers

Poor migrations cause cascading issues that can impact a business for months. A misconfigured transfer can lead to broken environments, plugin and theme conflicts, failed database imports, DNS misconfigurations, and SSL breakage. 

Additionally, according to the 2024 ITIC Reliability Survey, over 90% of mid-sized and large enterprises lose more than $300,000 per hour of downtime, with a significant portion reporting losses between $1 million and $5 million per hour. Even for small businesses, the revenue impact of an offline site is severe, with some SMB sources reporting as much as $100,000 lost per hour of downtime.

Furthermore, a2025 industry analysis by Kaopiz Global reveals that a staggering 83% of data migration projects fail to meet their objectives, often significantly exceeding their allocated budgets and timelines due to poor execution. 

Technical buyers correctly prioritize stability, speed, and risk elimination. A migration is often the single riskiest moment in a website’s lifecycle.

The modern expectation is simple: zero visible downtime, clean environment parity, and predictable rollback options.

Migration pre-checklist: What to verify before moving any site

A successful migration requires meticulous planning. Use this structured, developer-friendly checklist to prepare:

• Audit the current environment: Document the exact PHP version, database engine, caching stack, and file structure in use.
• Inventory assets: List all active plugins, themes, custom code snippets, and third-party integrations.
• Confirm access: Ensure you have working SFTP/SSH credentials, database access, control panel logins, and API tokens. Familiarize yourself with any new hosting portals and dashboard early on. For instance, if you’re migrating to WP Engine, tour the WP Engine User Portal at this point.
• Assess potential blockers: Identify large media libraries, multi-environment setups, or heavy customizations that require special handling.
• Ensure robust backups: Verify you have full, versioned backups from both the source and the destination environments.
• Identify dependencies: Check for cron jobs, specialized caching rules, or email routing tied to the old host.

7 website migration best practices for a smooth transition

Following a structured approach guarantees a safer transfer. Consider these seven pillars for your next project.

1. Use a staging or temporary environment first

Never migrate data directly to a live production server. Always clone your WordPress®¹ site to a staging environment. This provides a safe sandbox to test compatibility, resolve errors, and measure performance before public traffic hits the server.

2. Align PHP versions, database versions, and server configs

Environment mismatches cause the majority of fatal errors during a move. Document the exact configurations of the old host and replicate them on the new platform. Ensuring environment parity prevents broken code and unexpected downtime. 

If you cannot rollback the new hosting environment to your current environment versions, you’ll need to plan through how to upgrade and test the current environment before migrating.

3. Migrate database and content with validated tools

Using reliable tools prevents serialization issues, broken URLs, and permanent data corruption. A manual SQL export can easily corrupt serialized PHP arrays. WP Engine provides robust tooling to migrate a WordPress site safely, handling these technical details automatically behind the scenes.

4. Migrate media efficiently

Large media libraries require careful handling. Moving gigabytes of images via standard FTP is slow and prone to timeout errors. Instead, chunk the transfers, use rsync, or rely on host-assisted transfer protocols to ensure every file arrives intact.

5. Validate file permissions and environment variables

Incorrect file permissions are a common cause of broken assets, failed form submissions, and integration errors. Double-check that all directories and files have the correct ownership and permissions mapped to the new server architecture.

6. Update DNS with minimal downtime

Planning the domain name system (DNS) switch is crucial for zero-downtime migrations. Reduce the Time to Live (TTL) settings days in advance. This ensures that when you point your domain to the new host, the propagation window is as short as possible. Always establish a clear rollback timeline just in case.

7. Test everything before going live

Once the data is moved, test the staging site extensively. Check page load performance, review server error logs, click through navigation links, test caching layers, and verify redirects. Finally, run through transactional flows like checkouts, form submissions, and user logins.

Common migration pitfalls (and how to avoid them)

Managed platforms help prevent many of the standard issues teams face during a transition. Understanding these pitfalls allows technical teams to approach the problem proactively.

• Failing to match environment parity: Different PHP versions or missing extensions will crash a site. Always verify server specs before moving files.
• Migrating outdated plugins or themes: According to the Patchstack 2024 State of WordPress Security report, 96% of recently reported vulnerabilities originate from plugins. Update everything on the source site before migrating to avoid bringing security flaws to the new host.
• Missing DNS windows: Forgetting to lower TTL settings prolongs DNS propagation, leaving users seeing the old site for up to 48 hours. Plan the DNS strategy early.
• Media mismatches or partial transfers: Timeout limits often cause large image folders to fail halfway. Use command-line tools or automated plugins to verify file integrity.
• Serialized data breaking on import: Standard find-and-replace tools break serialized strings in the database. Always use a tool built specifically to handle these databases correctly.
• Overwriting custom code or staging changes: Moving data blindly can erase recent client work. Use Git or a structured deployment process to copy a site without overwriting custom commits.
• Lack of rollback plan: Never start a migration without a verified backup. If the new server fails, teams must be able to revert DNS and restore the original site instantly.

Choosing the right migration tools and workflows

Technical buyers have several options when evaluating a migration workflow. The right choice depends on the size of the site and the technical proficiency of the team.

• Automated migration plugins: These are user-friendly tools that package files and databases into a single payload.
• CLI-based migrations: Command-line interfaces offer deep control for developers comfortable with terminal commands.
• Database export/import tools: These require manual handling of SQL files and careful attention to serialization.
• Git-based deployments: Ideal for custom themes and plugins, allowing teams to push code predictably. To ensure code works perfectly before pushing, many developers use a local development environment.
• rsync/file transfer methods: Best for transferring massive media directories securely over SSH.
• Host-assisted migration services: Many platforms offer expert teams to handle the entire process.

Platforms offering automated migration plugins, expert-assisted options, staging environments, and consistency checks significantly reduce risk. Predictable, low-downtime workflows are a key decision factor, especially when handling complex agency site migrations or when planning a website migration for small businesses that are entirely web-reliant.

Performance considerations during and after migration

A migration is a valuable opportunity to fix long-standing performance blockers. Platforms optimized for performance help ensure the site is actually faster after the move, not just relocated.

A recent report of 2025 e-commerce performance statistics compiled by Kanuka Digital shows that websites loading in just one second achieve conversion rates 2.5 times higher than those taking five seconds to load.

Key performance settings to review on the new platform include:

• Rebuilding cache layers: Ensure object caching and page caching are actively functioning on the new server.
• Verifying CDN routing: Check that the Content Delivery Network is routing traffic correctly and applying edge rules.
• Confirming paths and redirects: Ensure that asset paths, 301 redirects, and compression settings match expectations.
• Ensuring background tasks run: Verify that WP-Cron jobs, message queues, and scheduled posts operate normally.
• Testing performance: Run speed tests on the new infrastructure to confirm Time to First Byte (TTFB) improvements.

How WP Engine simplifies and de-risks the migration process

WP Engine offers specialized infrastructure and tooling designed to make migrations safe, predictable, and fast. Technical teams choose the platform to reduce the operational friction associated with moving complex sites.

• Automated migration tools: WP Engine provides plugins engineered specifically for reliability and data integrity.
• Included environments: Every account includes dedicated development, staging, and production environments.
• Expert support: The support team is deeply familiar with complex transfers, including how to migrate an eCommerce site without losing order data.
• Performance-tuned architecture: The platform is built to improve speed and security immediately post-migration.
• Integrated backups: Daily automated backups and instant rollbacks provide peace of mind.
• Clear deployment workflows: Built-in tools allow developers to push code seamlessly between environments.
• Assisted options: Optional expert-assisted migrations are available for enterprise-level or highly complex architecture moves.

Migrate your website with confidence and control

Website migrations are not just a technical risk. They represent a powerful opportunity to improve performance, enhance reliability, and establish long-term maintainability for a digital asset. By preparing a thorough checklist, utilizing staging environments, and carefully managing DNS, developers can execute seamless transfers.

Using the right tools and leaning on specialized platforms takes the guesswork out of the process. If you are ready to explore a better way to host, WP Engine offers the tooling, platform features, and expert support that help teams execute safer, faster migrations.

FAQs about website migration best practices

How long does a typical site migration take?

A standard migration for a small to medium website usually takes between two to four hours of active work. However, DNS propagation can add an additional 24 to 48 hours before the transition is visible globally. Complex eCommerce stores or large media sites require additional planning, testing, and synchronization, extending the timeline to several days or weeks.

How can I avoid downtime during migration?

To avoid downtime, migrate data to a staging environment on the new host first. Test the site thoroughly via a temporary URL. Once the staging site functions perfectly, lower the DNS TTL settings, schedule the final data sync during off-peak hours, and update the DNS records to point to the new server.

What is the safest way to migrate large media libraries?

The safest way to move massive media directories is by using SSH and the rsync command. This method is faster than standard FTP, encrypts the data during transit, and can resume the transfer automatically if the connection drops. Alternatively, utilize host-assisted migration tools designed to chunk large directories and bypass standard server timeout limits.

How do I test a site properly after migration?

Testing requires a methodical approach. Start by checking the server logs for fatal errors. Click through the primary navigation to ensure permalinks work. Submit contact forms, complete a test purchase on eCommerce setups, and verify that the caching layers are active. Finally, use a performance tool to compare the new load times against the old environment.

The post The Developer’s Guide to Zero-Downtime Website Migrations appeared first on WP Engine®.