Fixing the 'This does not seem to be a WordPress installation' WP-CLI Error

The Problem

You fire up your terminal to run a quick wp plugin list or wp core update. Instead of the usual output, the terminal shuts you down with a blunt message: Error: This does not seem to be a WordPress installation. It is a common roadblock that usually means WP-CLI is lost and cannot find your site's core files.

Why WP-CLI is Getting Confused

WP-CLI identifies a valid installation by searching for wp-includes/version.php. If this file is missing from the search path, the tool assumes it is in the wrong directory. This typically happens for a few specific reasons:

• Wrong Directory: You are running the command from /var/www/ instead of the actual root at /var/www/html/.
• Path Mismatch: The --path flag you provided points to a folder that does not contain the core files.
• Custom Structures: You are using a boilerplate like Roots Bedrock where the WordPress core is tucked away in a /web/wp/ subfolder.
• Insufficient Permissions: Your user lacks read access to wp-load.php or the wp-includes folder.

Quick Fix: Verify Your Location

Most of the time, you are simply one directory away from success. Use pwd to see exactly where you are standing in the file system. Then, check for the presence of the WordPress loader file.

# See your current path
pwd

# Confirm if the core files are actually here
ls -la | grep wp-load.php

If the file is missing, move into the correct directory. For a standard Ubuntu setup, this is often /var/www/html:

cd /var/www/html
wp core version

Using the --path Parameter

You might need to run commands from outside the WordPress folder, such as within a deployment script or a cron job. In these cases, you must explicitly tell WP-CLI where the files live. Use the --path flag with an absolute directory string.

wp plugin list --path=/var/www/my-site.com/public_html

Avoid adding a trailing slash at the end of your path. Using /var/www/html is cleaner and less prone to internal pathing errors than /var/www/html/.

Solutions for Bedrock and Custom Stacks

Bedrock changes the game by moving the WordPress core into a subdirectory. If you run a command in the project root, WP-CLI will fail. You need to point the tool to the web/wp folder specifically.

# Standard Bedrock command execution
wp plugin list --path=web/wp

Save Time with wp-cli.yml

Manually typing the path every time is tedious. To automate this, create a wp-cli.yml file in your project root. This configuration file tells WP-CLI exactly where to look for that specific project every time you run a command.

Place this in your wp-cli.yml:

path: public_html
# Or for Bedrock users:
# path: web/wp

Now, as long as you are inside the project folder, you can run wp commands without any extra flags.

Resolving Permission Conflicts

If you are in the right folder but the error persists, check your file ownership. WP-CLI needs to read the core files to bootstrap the environment. If the files are owned by www-data (644 permissions) and you are logged in as a different user, you might be blocked.

# Check file ownership
ls -l wp-load.php

# Check your current user
whoami

If there is a mismatch, run the command as the web server user. This is a safer alternative to changing file permissions globally.

sudo -u www-data wp plugin list --path=/var/www/html

Final Verification

Run a simple version check to confirm everything is back on track. If you see a version number like 6.4.3, you have successfully reconnected WP-CLI to your site.

wp core version

Summary Checklist

• Are you physically inside the folder containing wp-load.php?
• Does your --path flag use an absolute path without a trailing slash?
• Does your user have read permissions for the wp-includes directory?
• If using Bedrock, have you pointed the path to the /wp subfolder?