A WordPress SEO audit starts by checking what the site currently publishes, not by installing another plugin. Verify search visibility, public URLs, sitemap and canonical output, then inspect representative theme templates and important content. Make changes on staging where possible, keep a restorable backup, and retest the public page after each change.
This guide is for an owner or editor who can access the WordPress dashboard and needs an ordered review. Menu labels vary slightly by version and host. Record the current value and the page where you observed it before changing settings.
Prepare safely before changing settings
List the WordPress version, active theme, important plugins, host and any caching or content delivery layer. This is an inventory, not a recommendation to install, remove or replace software. Choose a small set of important pages: the home page, one page from each major template, one post, one archive, and a form or product page if the site has one.
Confirm that a recent backup includes both the database and uploaded files, and that you know how to restore it. Where available, test changes in a staging environment first. Check whether staging is protected from public indexing and whether its forms, email and payment integrations are safely disabled or in test mode. Do not send real email or submit live payments as part of a routine audit.
1. Check the search visibility setting
In the dashboard, open Settings → Reading and review the option that discourages search engines from indexing the site. A checked box can be intentional on a private development copy, but it is usually a problem on a public site that should be discoverable. Do not change it until you have confirmed which environment you are viewing and whether the restriction is deliberate.
Then inspect the rendered page source and response for noindex directives, robots rules and access restrictions. Search visibility is not controlled by one dashboard checkbox alone. A plugin, theme, host, reverse proxy or staging rule can add separate instructions. Compare the output from two representative public pages and test the exact live URL without being signed in.
WordPress's official search engine optimization documentation describes the built-in settings and general practices. A setting that permits crawling is not a promise that a search engine will index the page.
2. Verify the sitemap and public URL signals
WordPress core can publish XML sitemaps. Open the sitemap path for the actual site and check that it returns XML, lists canonical public pages and avoids private, staging or irrelevant paths. Sitemap output can be filtered by plugins, themes or site configuration, so test the live response instead of assuming it is enabled. The WordPress core sitemap announcement and documentation explains the core feature.
Open representative pages and record their canonical URL, robots instructions, response code and any redirect chain. If a plugin and theme both emit canonical tags, compare their destinations. A mismatch between canonical, internal links and sitemap entries can send conflicting signals. Choose one intended URL form, such as the site's HTTPS and host variant, and verify redirects end there.
3. Review permalink and canonical behavior
In Settings → Permalinks, record the current structure. A change to permalink rules can alter existing URLs across posts, pages, categories or custom post types. Do not change it just because a different pattern looks cleaner. First inventory affected URLs, identify a safe redirect plan, and test the result on staging. Never remove the old route until the new one and its redirects have been verified.
Check for duplicate canonical output from the theme and SEO plugin. For a few pages, compare the canonical in the raw source, rendered DOM and sitemap. Inspect pagination and archive pages as well. If the values disagree, identify which component creates each one before changing a setting. Avoid outputting a new canonical tag manually until you know whether one is already present.
4. Inspect content, archives and theme templates
For each representative page, check that the visible title matches the page topic, the primary heading is understandable, the main content is present without an editor login, and links lead to current destinations. Review image alternatives for meaning, not keyword stuffing. Check that category and tag archives have a clear purpose and are not exposing large sets of empty or duplicate pages.
Inspect the active theme at desktop and phone widths. Test menu operation, heading hierarchy, visible focus, form labels, validation feedback, zoom and horizontal overflow. A plugin can generate useful metadata, but it cannot repair a theme template that hides the main content or blocks keyboard use.
5. Measure images, scripts and page behavior
Test the exact pages and templates that feel slow or unstable. Look for oversized images, unreserved image dimensions, font changes that move text, render-blocking scripts and third-party widgets. Compare field data from real visitors with lab measurements that help reproduce a controlled problem. Google's Core Web Vitals guidance explains the current user-experience metrics and how to interpret them.
Fix the observed bottleneck rather than installing a caching, image or SEO plugin by default. WordPress caching behavior depends on the host and current stack. Adding another layer can create stale pages, broken logged-in flows or duplicate optimization work. On staging, change one relevant setting, purge only the appropriate cache, and retest the same URL and behavior.
Troubleshooting table
| Symptom | What to inspect first | Safer next step |
|---|---|---|
| Public pages are not appearing in search | Reading visibility setting, response headers, robots directives, page-level noindex and host rules | Confirm the environment and intended access policy, then remove only the accidental block and retest |
| Sitemap is missing or has duplicate URLs | Core sitemap response, plugin sitemap settings, canonical output and redirects | Identify which component owns the public sitemap before changing or disabling anything |
| Search results show an unexpected URL | Canonical tags, internal links, sitemap entry, redirect destination and pagination | Align signals with the intended URL and test the old and new routes |
| A title or canonical appears twice | Theme output, SEO plugin output and any custom snippets | Change one source after confirming which component produced each tag |
| Mobile page is slow or jumps during load | Largest visible image, image dimensions, font swap, third-party scripts and template | Reproduce on one template, change one cause on staging, then compare equivalent tests |
| A permalink change breaks incoming links | Previous URL inventory, rewrite rules, redirects and custom post types | Restore or map old URLs until every important route has a verified destination |
6. Use a review worksheet
Keep one row per URL or shared template. Write down actual values and evidence instead of just checking a box.
| URL or template | Setting or behavior | Evidence and current value | Owner | Planned change | Retest |
|---|---|---|---|---|---|
| Search visibility, robots or canonical | |||||
| Sitemap or permalink response | |||||
| Mobile, keyboard or form journey | |||||
| Image, script or layout performance |
Fictional example and order of operations
Suppose a fictional business intentionally keeps its staging copy excluded from search and intends only its public production site to be indexed. During a production review, the owner also finds that the theme and SEO plugin both emit canonical tags, and a mobile image shifts the enquiry form after load. This example is hypothetical, not a measured site result.
First, confirm that the noindex or access restriction on staging is deliberate and should remain in place. Confirm that production is the public site meant to be indexed, then record its search visibility, robots state and canonical output. Next, identify whether the theme or plugin emitted each production canonical before editing either. Reproduce the mobile shift on the same page and inspect the image dimensions. Take a backup, make one change at a time on staging, verify the change there while keeping its exclusion in place, then repeat the original checks on the production URL after a planned release.
Use this order for your own site:
- Confirm the environment, backup and representative URL set.
- Check visibility controls, robots responses and public access.
- Review sitemap, canonical, redirects and permalink behavior.
- Inspect theme templates, content and mobile task completion.
- Diagnose measured performance symptoms.
- Make one reversible change, then verify the same URL and behavior.
For a broader repair queue across templates, see the website audit checklist for evidence-based repairs. Before a paid campaign, use the narrower pre-campaign website checklist.