An automated scanner shows symptoms: duplicates, redirects, missing tags. The cause usually sits deeper: a plugin conflict, the theme’s output, response headers, an update that changed the canonical three weeks ago. We run a WordPress site audit as an investigation: we collect data from several independent sources, combine it into one picture, and prove every cause with a specific URL, a response header, or a fragment of page code.

Who Runs the Audit

We build, optimize and promote websites. We own dozens of monetized projects, so we know how ads, affiliate links and scripts affect speed and rankings. We write WordPress plugins, some of them published in the official directory, and we build optimized themes. We know how plugins behave in code, where they conflict, and which small detail changes the output of tags across thousands of pages.

What a WordPress Site Audit Is

A WordPress site audit is a check of how search engines crawl, index and understand your pages, and which settings, plugins and theme get in the way. You get a prioritized list of fixes that names the cause and where it lives, not a scanner export.

How We Run a WordPress Site Audit

1. We collect data from independent sources

Google Search Console: the page indexing report broken down by exclusion reason, crawl stats (server responses, response time, file types), performance by query and page, the Core Web Vitals report, URL Inspection (your declared canonical versus the one Google selected, rendered HTML, screenshot), manual actions and security issues, and the links report.
Analytics: organic traffic by page type, not just for the site as a whole.
Link databases: Search Console plus several external indexes (for example Ahrefs, Majestic, Semrush), because no single database sees the whole link graph.
Site history: archived copies of pages (Wayback Machine) and the change history you share with us.

2. We cross-check traffic dynamics against Google updates and site changes

The first thing we establish is why traffic changed. We overlay two timelines. The first holds Google algorithm updates (core updates, spam updates, helpful content system updates, as listed on the Search Status Dashboard). The second holds your changes: plugin and theme updates, migrations, structure changes, added languages, code edits.

Algorithmic and technical causes look different in the data. A technical error hits a group of URLs united by a template, a plugin or a section, and its date almost always matches a change on the site. An algorithmic reassessment usually affects the site broadly, and different page types decline in sync. We separate these cases with data rather than guesswork.

3. We reconcile URL lists from different sources

For every site we compare the sitemap, a crawl (with and without JavaScript rendering), the Search Console index, and pages with traffic from analytics. The gaps between these lists are the findings: pages in the sitemap but not in the index, pages in the index that are missing from the sitemap, pages with traffic that a crawler cannot reach through internal links, and URLs that Google crawls but that have never brought traffic.

4. We check what Google sees, not what we see

Source HTML and rendered DOM. We compare them: what makes it into the render, what loads via scripts, and what appears only after user actions.
Response headers: X-Robots-Tag, the Link header with a canonical, Cache-Control, Vary, redirect chains. A noindex in a header is invisible in the HTML, so it is often missed.
Live URL Inspection in Search Console shows Googlebot’s actual response, not a User-Agent spoofed in a crawler.
Cloaking and hack checks. We compare the response for a regular browser and for the Googlebot User-Agent, and look for hidden links, spam pages in the index (a site: search), swapped content, and redirects that only fire for visitors coming from search.
Public service endpoints: robots.txt, sitemaps, the REST API, author enumeration, and responses to nonexistent URLs and old slugs.

5. We analyze page code and loaded resources

A WordPress site audit without code analysis misses conflicts. From the page source we determine what runs on the site and how the parts interact:

which plugins, theme and page builder are active and in which versions, based on script and style paths, HTML comments and REST API responses;
the order and duplication of tags in head: several title, robots, canonical, Open Graph and hreflang tags from a plugin, the theme and core at the same time;
structured data: types, identifiers, whether it matches visible content, and conflicts between a plugin, the theme, WooCommerce and review plugins;
what the cache and optimizer output: “frozen” canonical and hreflang tags, deferred loading of links and content that never reaches the render;
template structure: heading hierarchy, navigation, pagination, links without href, content that exists only in the DOM after scripts run;
before and after comparisons of a page (from archived copies and data you provide) to see what changed in the output after an update or migration.

If we have admin access, we also review the settings of the SEO plugin, cache, multilingual setup and redirects to find the source of the discrepancies seen in page code.

6. We analyze the link profile

We merge data from several databases and remove duplicates. Then we look at:

referring domain dynamics and spikes that do not match your publications;
anchor text distribution and the share of commercial anchors;
topical relevance of donors and the “neighborhood” of a link: what else is on the donor page and where the donor links;
signs of site networks: a shared template and outbound link patterns;
links from hacked sites, redirects from expired domains, and spam spikes;
pages with external links that return 404 or a redirect: such links can be recovered with a correct redirect;
internal link equity: where it flows and what gets little.

We recommend disavowing links only when there is a manual action or genuinely unnatural links, because Google advises most sites to manage without it.

7. We analyze queries and content

Cannibalization: several pages of the site compete for one query and swap places in the results.
CTR relative to position, and mismatch between a page and query intent.
Outdated content that has lost positions over time, and thin or repetitive pages that drag down the evaluation of the whole site.
Trust signals: authorship, sources, contact details, author and company pages.

8. We measure speed by template

Field data (CrUX, the Core Web Vitals report in Search Console) by page type, with lab tests used for diagnosis.
Which scripts and styles each plugin loads and on which pages they are not needed.
The LCP element and how it loads, layout shifts, interface responsiveness (INP), and server response time from external measurements.
On monetized projects, separately: ad slots without reserved height, heavy affiliate and ad scripts, and ad density in the first screen.

What We Find Most Often

A noindex in the response header (server, CDN, staging settings). The page looks fine but drops out of the index.
A canonical and noindex conflict, or a canonical pointing to a page that redirects. Google picks the canonical itself and ignores the declared one.
Two sources of SEO tags: a plugin and the theme, or two plugins, output different titles, canonicals, Open Graph and structured data.
WordPress side pages in the index: attachments, author and date archives, internal search, ?replytocom= links, WooCommerce filters.
Pagination on a static front page returns the same list on every page.
Multilingual setups: hreflang without a region, a front page URL like /en/home/ with a static front page, and breadcrumbs and sitemaps that keep linking to it.
Cache and script optimization that “freeze” canonical and hreflang tags or defer links and content so they never reach the render.
Changes after a plugin or theme update: robots, markup or redirects changed, while the reports show only a traffic drop.
A hack with no visible signs: spam pages and hidden links shown only to Googlebot.

What You Get from the Audit

A report where every issue is backed up: a URL, a response header, a fragment of page code or Search Console data.
Priorities by impact on traffic and effort to fix: critical (blocks indexing), important, improvements.
A timeline of what affected traffic and when, matched against Google updates and your changes.
Ready recommendations for settings, code and redirects. If you open access, we implement the fixes ourselves.
Plugin and theme recommendations: what to disable, what to replace, and which plugin owns which function.
A follow-up check after implementation using Search Console data.

From Audit to Promotion

We run projects end to end: optimization, code work, content, promotion. It makes sense to build links only for a site without technical errors, so the audit comes first. After it, you can order backlinks from topical sites in our portfolio. We select sites that fit your site’s profile and keep an eye on how natural the link profile looks.