SEO guide for business owners

WordPress SEO Audit: Look Beyond Your Plugin Settings

A business-focused WordPress audit starts with important pages, not plugin scores. Use this guide to identify real problems, choose safe changes, and ask for evidence that the work was implemented correctly.

The short answer

Check whether your important pages are accessible, eligible for indexing, and useful to prospective customers. Then review archives, canonical URLs, sitemaps, internal links, and template performance. A plugin can manage settings, but its score cannot confirm that Google selected the right page or that a visitor can complete an inquiry. Prioritize verified problems affecting business-critical pages over cosmetic warnings.

01

A key service page is missing from search

Check: Inspect the exact URL in Search Console and compare its live indexing directives with Google's recorded version.

Next: Fix a confirmed access or indexing restriction before rewriting the page.

02

An archive appears instead of the intended service page

Check: Compare the pages' purpose, query data, content, and internal links.

Next: Clarify which page should answer the query; do not automatically disable every archive.

03

Plugin scores look good, but inquiries are scarce

Check: Review landing-page intent, offer clarity, mobile forms, and inquiry measurement.

Next: Address the visitor's decision and contact process rather than adding keywords for a higher score.

04

Pages became slow after an update

Check: Compare affected templates, recent changes, and repeatable mobile tests.

Next: Reproduce the issue on a protected test copy before changing caching or disabling plugins.

Start with pages that matter to the business

A useful audit asks whether WordPress is helping the right visitor reach the right offer. I recommend starting with a small, representative sample: your main service or product page, an important category, a supporting article, and a contact or purchase page. Add an affected page if you are investigating a specific problem. This establishes priorities without treating every URL as equally valuable.

For each page, record its purpose, intended customer question, desired next action, and template type. Gather Search Console access, analytics where available, the sitemap, and a list of recent site changes. Missing analytics is a measurement gap, not proof that a page produces no inquiries. Record the current state before editing anything.

The first output should be a short list of business questions, not hundreds of automated warnings. If you need help interpreting that evidence, WordPress SEO support should connect the settings to page-level decisions rather than simply configure another plugin.

Verify indexability on the actual page

Indexability means a page is technically eligible to appear in search; it does not mean Google will include it. Check WordPress's search engine visibility setting, the page's own noindex setting, and any access restrictions. A noindex directive tells search engines not to index the page. Robots.txt controls crawling, so blocking a URL there is not a substitute for noindex. Google must be able to crawl the URL to read its noindex directive.

Inspect the exact URL in Search Console. Compare Google's recorded indexing status with the live test, the HTTP response, and the directives the page actually serves. A published page may still return an error, point elsewhere, or inherit a template-level restriction. Conversely, an intentionally excluded thank-you page may need no repair.

Keep these checks separate from ranking questions. A page can be indexed and still receive little visibility. A Google search using the site: operator is not a complete inventory of indexed pages. If absence from Google is the main problem, use the guide to diagnosing missing search visibility rather than changing unrelated WordPress settings.

Decide which archives to keep in search

WordPress can generate category, tag, author, and date archives from the same articles. That does not make every archive useful for search, or every overlap harmful. My recommendation is to assess whether each archive offers a distinct browsing or search purpose. A well-maintained topic directory deserves different treatment from a tag created for one post.

The following worked example is illustrative: a hypothetical commercial refrigeration repair business publishes maintenance advice. These are conditional decisions, not client results or blanket rules. Before changing an archive type globally, check existing search visibility, links, navigation use, and whether the setting also affects useful archives.

Illustrative archive decisions for a hypothetical repair business
ArchiveEvidence to inspectRecommended decisionAcceptance check
Maintenance categoryGroups distinct guides customers needRetain and improve its introduction and navigationUseful articles remain reachable through ordinary links
One-post equipment tagRepeats a listing with no separate user purposeConsider noindex while retaining it for browsingArchive serves noindex; the article remains indexable and linked from other indexable pages
Single-author archiveMostly repeats the blog listingConsider excluding the listing from search; preserve the author biographyAuthor information remains accessible on relevant content
Monthly archiveCustomers choose by equipment issue, not publication monthKeep only if useful for browsing; otherwise consider retirementNavigation has no broken links; any redirect has a relevant destination

Align canonicals, sitemaps, and redirects

A canonical identifies the preferred URL among duplicate or very similar pages. Google treats canonical signals as preferences, not commands, and may choose another URL. Redirects and canonical annotations are stronger signals than sitemap inclusion. A sitemap helps communicate preferred URLs; it does not guarantee indexing.

For your sample pages, compare the final destination, declared canonical, sitemap entry, and internal-link destination. Investigate disagreements. For example, after an old service page redirects to its replacement, menus should link directly to the replacement rather than rely on that redirect. Keep intended canonical, indexable pages in the sitemap rather than old redirecting addresses.

Do not point every archive's canonical to the homepage or change established permalinks just to make them shorter. Those are not universal repairs. Check whether the theme and multiple plugins are producing conflicting tags. Give each function a clear owner, but document and test any removal before disabling software.

Google Search Central: Consolidating duplicate URLs

Test speed changes without breaking the site

Measure representative templates on mobile, not just the homepage once. Core Web Vitals describe loading, responsiveness, and visual stability. Where available, real-user measurements show actual visitor experience, while lab tests help reproduce a problem under controlled conditions. Record the page, device conditions, and repeated observations before blaming hosting or a plugin.

Investigate the specific symptom: an oversized banner, delayed server response, excessive scripts, or a layout shift when a booking widget loads. Test changes individually on a protected staging copy with a recoverable backup. After changing caching or script loading, check navigation, consent behavior, forms, and checkout. A faster page with a broken inquiry form is not an acceptable release.

Template code, server rules, and complex conflicts often need technical SEO investigation coordinated with a developer. A domain, URL, or major platform change needs a separate migration checklist, not an improvised extension of a speed cleanup.

Assign fixes and check the results

I recommend prioritizing a confirmed blocker on a revenue-relevant page before a minor presentation issue across low-value archives. For each finding, specify the affected URLs or template, observed evidence, proposed change, responsible person, and acceptance test. Keep suspected causes separate from confirmed faults. The SEO audit deliverables guide explains what to request beyond an exported error list.

A site owner can usually confirm service details and approve navigation or content changes. An SEO specialist should evaluate indexing and page-purpose decisions; a developer should handle changes requiring code or infrastructure expertise. Most of my implementation work is in WordPress, with specialist development coordinated with the client's developers.

After release, verify the live output and record the change date. Google allows recrawl requests for individual URLs through URL Inspection, but a request does not guarantee immediate crawling or inclusion. Confirm implementation first, then monitor indexing and business-relevant behavior; a successful technical test is not evidence of increased inquiries.

Google Search Central: Requesting a recrawl

Common questions

Do I need to replace Yoast or Rank Math before an audit?

Usually not. First inspect the site's output and identify any limitation or conflict. Changing plugins adds migration work and can alter metadata, schema, or indexing settings without fixing the underlying issue.

Should all tags and author archives be noindexed?

No. Judge their purpose and evidence individually. A useful editorial directory may deserve search visibility, while a repetitive listing may not. Noindexing an archive does not automatically require noindexing the posts it lists.

What proves that an audit fix worked?

Use the acceptance test agreed for that issue: the correct directive, a working redirect, a crawlable link, or an intact form after optimization. Later search and inquiry trends answer different questions and should not be attributed to one change without supporting evidence.

Sources and further reading

Practical guides

For your next decision.

Understand the problem, compare your options and choose the right support.

All SEO guides