The command wp core verify-checksums compares installed WordPress core files with checksums for an official version and locale. A mismatch can come from malware, a partial update, a modified bundled file, the wrong version or locale, an unexpected root file, or an incomplete deployment. The command is valuable because it narrows the file investigation, but it does not inspect the database, uploads, premium plugins, custom code, must-use plugins, scheduled tasks, administrator accounts, or persistence outside the WordPress directory.
Use this after an integrity alert, suspicious redirect, failed core update, unexplained PHP change, security scan, or Search Console warning. It is also useful as a release gate after WordPress 7.1 deployment.
Quick answer
Run wp core version and wp core verify-checksums with the intended locale and --include-root when you also need to inspect unexpected files in the installation root. Save the raw output before changing anything. Separate checksum failures from unknown files, confirm that the installed version matches the expected release, preserve suspicious files for review, and replace core only from a trusted package. A clean second run confirms core file parity, but it does not prove the whole site is clean.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Correct version and locale | Official WordPress files | No checksum failures |
| Partial update | One old core file | Mismatch maps to release evidence |
| Unknown root file | include-root enabled | File is preserved and classified |
| Compromised site | Core plus persistence review | Repair covers more than checksums |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze and preserve evidence | Record the site path, reported core version, locale, deployment time, web node, filesystem owner, and current maintenance state. | The expected core version and locale are documented for every production node. |
| Confirm version and locale | Run the core checksum command without insecure transport and save standard output, warnings, and exit status in the incident record. | The second checksum run is clean or every approved exception has an owner and reason. |
| Classify every path | Classify modified official files, missing files, and unknown root files separately because each class has a different explanation and repair path. | Unknown root files, wp-content, database accounts, cron, and must-use plugins received separate review. |
| Replace core from a trusted source | Compare every flagged path with deployment logs, recent updates, security alerts, access logs, administrator activity, and known customization records. | Public pages, wp-admin, cron, REST requests, forms, and checkout still work after the trusted replacement. |
What to check first
- Record the site path, reported core version, locale, deployment time, web node, filesystem owner, and current maintenance state.
- Run the core checksum command without insecure transport and save standard output, warnings, and exit status in the incident record.
- Classify modified official files, missing files, and unknown root files separately because each class has a different explanation and repair path.
- Compare every flagged path with deployment logs, recent updates, security alerts, access logs, administrator activity, and known customization records.
- After trusted replacement, rerun checksums and inspect wp-content, database users, cron, must-use plugins, and external persistence before closure.
Field notes
- Write the expected result before making a change and keep one repeatable canary fixture.
- Record versions and timestamps because release, cache, and delivery behavior can change between tests.
- Use one canonical owner page for each query family and give every supporting page a distinct task.
- Close the incident only after the public workflow and the downstream record both pass verification.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp core version
wp option get WPLANG
wp core verify-checksums --include-root --format=json > core-checksums.json
# Preserve flagged files before replacement.
wp core download --skip-content --force
wp core verify-checksums --include-root
Why this usually happens
- A rolling or interrupted update can leave web nodes on different core builds.
- A host or deployment tool can preserve files that a clean package no longer contains.
- Manual edits to core make later integrity results noisy and hide meaningful changes.
- Malware can modify official files or place new files in locations that core-only verification does not cover.
Decision rule
Replace core files only after the expected version and locale are confirmed and suspicious files are preserved. Escalate to a full incident response when unknown executables, repeated reinfection, unauthorized administrators, database payloads, malicious cron, or unexplained outbound traffic appears.
Production verification checklist
- The expected core version and locale are documented for every production node.
- The second checksum run is clean or every approved exception has an owner and reason.
- Unknown root files, wp-content, database accounts, cron, and must-use plugins received separate review.
- Public pages, wp-admin, cron, REST requests, forms, and checkout still work after the trusted replacement.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze and preserve evidence
- Confirm version and locale
- Classify every path
- Replace core from a trusted source
- Audit persistence and verify again
Mistakes to avoid
- Changing production files, recipients, hooks, cache settings, or update policy before preserving the failing request and current configuration.
- Treating one warning, one successful test, or one dashboard status as a complete diagnosis without checking the next system in the path.
- Testing with a different account, order state, form embed, locale, plugin version, or cache state than the real failure.
- Publishing a new broad answer when an established owner already exists, which splits internal links and creates query overlap.
Questions teams ask during testing
Can I run this directly on production?
Read-only inspection is often appropriate on production when access is controlled and output is redacted. Make backups first, test state-changing steps on staging, define rollback, and schedule any production change for a monitored window.
How do I avoid a false positive?
Match the exact installed version, locale, request, order, form, role, cache state, and integration path. Repeat the same fixture after the fix and keep evidence from both runs.
What evidence should I keep?
Keep UTC time, site and plugin versions, request or record ID, command, expected result, actual result, relevant logs, configuration snapshot, change, rollback point, and final verification. Redact secrets and personal data.
When should a specialist take over?
Escalate when checkout, customer email, lead capture, security, payment state, production updates, or several plugins are affected, or when the safe next step is unclear. A short evidence packet saves time and limits guesswork.
What to tell the client or owner
Give the site owner a concise evidence packet containing the affected workflow, exact versions, UTC test time, fixture or record ID, expected and actual result, logs, change made, rollback point, final verification, owner, and next review date. Remove passwords, tokens, payment details, and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP investigate the WordPress files and persistence paths.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Rule out a version or locale mismatch first
Use the WP core checksum locale and version decision tree before replacing files. It separates the wrong package identity, localized files, partial origin rollout, approved changes, unknown root files, and likely compromise.
Helpful references