Platforms: WordPress
A WordPress site can have its SEO plugin set up correctly and still ship broken pages. Plugin updates, theme changes, new content types, permalink edits, and migrations all change what crawlers actually receive.
This hub treats WordPress SEO as ongoing validation. You crawl the rendered site, run the same checks on every page type, and compare the result with an earlier crawl.
Learn the audit workflow here, then open the guide that matches what just changed on your site.
Technical audit focus. Works with any WordPress SEO plugin, theme, or page builder.
Definition
A WordPress SEO audit checks what the site delivers, not what the settings screen says. It looks at the rendered HTML a crawler receives, the URLs and status codes behind it, and the metadata, indexability signals, internal links, and structured data on each page.
It also looks at how each template behaves. WordPress builds most pages from a small set of templates, so one change in a template can affect hundreds of URLs at once.
A plugin can report that a setting is on. Only a crawl shows whether the page output matches it.
Two different jobs
Why it matters
WordPress changes constantly, and most of those changes happen outside the page editor. These are the five situations that cause repeat problems.
An update can alter title templates, canonical tags, robots meta tags, or schema without touching your content. The editor looks the same, so nobody notices until rankings or indexing move.
A single template with two H1 tags or a missing canonical repeats the problem on every post, page, or product that uses it. Fixing it once fixes the whole group.
Category, tag, author, date, and paginated archives are generated automatically. Without a check, they can add pages you never planned to rank.
A new URL structure can strand internal links, create redirect chains, and leave old URLs in the XML sitemap.
Metadata, canonicals, URL structures, and indexability can all shift on launch day. Without a comparison, you find out from a traffic drop.
Reference
The checks are grouped by technical category, not by plugin, so the same list works whichever SEO plugin or theme the site uses.
Confirm that the right pages can be crawled and indexed, and that the signals agree with each other.
WordPress note: the “Discourage search engines from indexing this site” setting is easy to leave on after a staging launch. Check the robots meta on live pages.
Find metadata that is missing, duplicated, changed unexpectedly, or generated incorrectly by a template.
Look for missing or multiple H1 headings, inconsistent page headings, and problems the theme introduces through its templates.
Check that permalinks are consistent, redirects go straight to the right destination, and internal links point at live URLs.
Test each page type once, then confirm the result across every URL that uses the template.
Validate the schema in the rendered page, not only the plugin settings, and check that the type matches the page.
Find images without alt text, broken assets, pages that are hard to discover, and inconsistent internal linking.
Check whether the important SEO elements appear in the HTML delivered to crawlers, including when a theme or builder adds them with JavaScript.
Related: JavaScript SEO explains how rendering affects what crawlers see.
Workflow
Follow the same seven steps every time. A repeatable process is what makes two crawls comparable.
Crawl the site before you change anything and save the result. This is the record every later crawl is measured against.
Open one post, page, category, tag, author archive, and product if you run WooCommerce. View the rendered source and confirm title, canonical, robots, headings, and schema.
Run a full crawl and sort by issue type. Patterns across many URLs usually point to one template, plugin, or setting.
Ten thousand URLs with one cause is one task, not ten thousand. Grouping keeps the fix list short and ordered by impact.
Change the source of the problem rather than patching individual pages, then note what you changed and where.
Confirm that fixed issues are gone and that the fix did not introduce new ones elsewhere.
Write down what remains open and set the next crawl date, ideally tied to the next planned update or release.
Change-based QA
Different changes break different things. Each guide answers one question and starts from the workflow above.
What broke after an update?
Titles, canonicals, indexability, headings, and schema can all change when code updates.
Unique angle: pre-update baseline, post-update checks, regression detection.
Read the update guideWhich page types share the same defect?
Recurring problems show up across posts, categories, tags, author pages, and product pages.
Unique angle: template-level testing, archive behavior, representative URL sampling.
Read the template guideDid the URL changes break SEO signals?
Redirects, internal links, canonical URLs, and sitemap URLs all depend on the permalink structure.
Unique angle: redirect mapping, internal link validation, canonical and sitemap checks.
Read the permalink guideWhat changed between the old and new sites?
Lost metadata, changed URLs, new errors, and indexability shifts are easiest to find by comparing crawls.
Unique angle: URL mapping, metadata preservation, crawl comparison, launch QA.
Read the migration guideRegression detection
A single crawl tells you what is wrong today. Two crawls tell you what changed, which is usually the faster route to the cause.
Keep a crawl record from before each update, redesign, or permalink change. After the change, compare the same URLs and the same SEO elements. New issues point to regressions, and issues that disappear confirm your fixes.
SiteAuditLint keeps audit history and shows new, fixed, and changed issues between crawls, so the comparison does not depend on spreadsheets. See Audit Comparison for how it works.
| Check | Baseline | After update | Change |
|---|---|---|---|
| Indexable URLs | 1,420 | 1,563 | +143 |
| Pages with a canonical tag | 1,418 | 1,275 | -143 |
| Tag archives set to index | 0 | 143 | +143 |
| Pages with exactly one H1 | 1,402 | 1,402 | 0 |
| Internal links to 4xx pages | 3 | 3 | 0 |
Numbers are made up to show the method. In this example, one update made 143 tag archives indexable and dropped their canonicals.
Examples
These six problems come up again and again. Each one is easy to miss in the dashboard and obvious in a crawl.
| Finding | Likely cause | What the crawl shows |
|---|---|---|
| A plugin update removes or changes canonical tags | Changed plugin defaults or a conflict between two SEO sources | Pages with no canonical, or canonicals pointing at a different URL than before |
| A template creates duplicate H1 headings | Theme prints the title as H1 and the content also contains an H1 | Many URLs of one page type with more than one H1 |
| A category archive becomes indexable unintentionally | Archive setting reset or changed in a plugin update | Archive URLs with index robots meta that were noindex in the baseline |
| A permalink change creates broken internal links | Hard-coded links in content, menus, or widgets still use old URLs | Internal links returning 404, or passing through redirects |
| A redesign removes metadata or changes status codes | New theme ignores existing title and description fields | Missing titles and descriptions, and URLs whose status changed from 200 |
| A sitemap keeps URLs that now redirect or error | Sitemap cached or generated from outdated rules | Sitemap URLs returning 3xx, 4xx, or 5xx responses |
<head>
<title>Blue Widget | Example Store</title>
<link rel="canonical"
href="https://example.com/blue-widget/">
<meta name="robots" content="index, follow">
</head>
Canonical present and matching the page URL.
<head> <title>Blue Widget | Example Store</title> <!-- canonical tag missing --> <meta name="robots" content="index, follow"> </head>
Same page, no canonical. Only a crawl of the rendered HTML catches it across every URL.
Checklist
Reuse this list for every audit. It covers the baseline, the main technical checks, and verification after a change. For a full version, see the technical SEO checklist.
Tooling
Four kinds of tools each answer a different question. They work together, and none of them replaces the others.
Set titles, canonicals, robots rules, sitemaps, and schema, and get content-level suggestions while editing.
Does not show: what the finished pages look like across the whole site.
Shows search performance and the indexing status Google reports for your URLs.
Does not show: every on-page technical signal, or problems before Google recrawls.
Fetch every URL and report status codes, metadata, headings, links, and technical signals the way a crawler sees them.
Does not show: what changed, unless you keep and compare earlier crawls.
Sets two crawls side by side to expose regressions and confirm that fixes worked.
Needs: a saved baseline from before the change.
WordPress SEO problems rarely come from a single page. They come from templates, plugins, and site changes, so the reliable check is a full crawl before and after each change. SiteAuditLint runs that crawl from your own computer and keeps the history for comparison.
Free version audits up to 100 URLs per crawl. Pro adds audit history and comparison.
Keep going
Start with the guide that matches your change, then use the general technical SEO material for the details behind each check.
WordPress guides
Technical SEO
In SiteAuditLint
Crawl your WordPress site, review issues by cause, and compare each crawl with the last one.