Technical SEO for WordPress beyond plugin settings
On a WordPress site large enough to have a search problem, the problem is almost never a setting. It is the URL structure, the archives nobody chose, or a template defect affecting every page of a type at once.
WordPress generates an estate nobody designed
A WordPress site accumulates URLs through its own mechanisms: taxonomy archives for every tag and category, author archives for every user, date archives, attachment pages for every uploaded file, search result pages, and pagination for all of them. Nobody decided to publish most of those. They exist because the platform generates them, and on a site with ten thousand posts the generated estate is far larger than the authored one — and the search consequences of that are not handled by any plugin.
- The indexed page count is several times the number of pages anyone wrote
- Tag, category, author and date archives are being indexed and are thin or duplicate
- Crawl activity concentrates on paginated and filtered URLs rather than content
- Impressions are spread across many near-identical URLs for the same subject
- A page type has lost visibility entirely and the templates look fine
- Pagination beyond the first pages is inconsistent — indexed on one section, not another
- Attachment or media pages appear in search results
- The site is slow to respond and the crawl rate has fallen, so new content is found late
The people who usually bring us this problem
A large WordPress site with a search problem
The plugin is installed and the site still has an indexation, duplication or discovery problem.
A publisher or store with thousands of URLs
The generated estate is the dominant part of the site and nobody designed it.
Someone whose traffic flattened as the site grew
Growth added content and URLs, and the added URLs are competing with the content.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
WordPress publishes more than you wrote, by default
Every taxonomy term, every author, every date with a post, every attachment, every search query parameter combination that a crawler tries. The platform's defaults are reasonable for a blog and wrong for a large site, and the decision about which of them should be indexable has to be made deliberately and expressed in code rather than in settings.
Duplicate and near-duplicate pages divide the signals
An archive listing the same posts as a category page, a paginated set whose pages compete with each other, a tag and a category describing the same subject, an attachment page duplicating the post it was uploaded to. Each pair splits the evidence that either page would otherwise accumulate, and the effect is invisible per page while being substantial across the estate.
A template defect affects every page of a type at once
A canonical generated from the wrong value, a structured data block emitted for the wrong type, a heading hierarchy that depends on a field being filled, content loaded by JavaScript that a crawler does not execute. One such defect can cost the visibility of an entire page type, and it looks like a content or ranking problem from outside.
Query cost and crawl rate are connected
A slow or unstable response reduces crawl rate, which delays discovery and re-evaluation. On WordPress this is frequently the database — an unindexed meta query, a taxonomy query assembled dynamically, a filter applied through a plugin's own layer — and the search consequence appears before anyone connects it to performance.
Capabilities
Each of these is work we carry out, not an area we advise on.
URL and routing structure
What the site's addresses are and what generates them: permalink structure, custom post type and taxonomy slugs, and the routing rules that decide which URL resolves to what. On a migrated site this is also where inherited structures and their redirect obligations live.
Generated estate audit
Every URL class WordPress produces, established rather than assumed: archives, taxonomies, authors, dates, attachment pages, search URLs, pagination and any plugin-registered routes. This is the inventory the decisions are made against, and on most sites it is larger than expected.
Indexation decisions expressed in code
Which of those classes should be findable and which should not, implemented at the template or filter level rather than left to a plugin's defaults — including the canonical, robots and internal-linking consequences of each decision, which have to agree with one another.
Duplicate and near-duplicate resolution
Canonical strategy for the pairs that exist: archive against category, paginated sets against their first page, attachment against parent, filtered views against the unfiltered set. Resolved deliberately, with the choice of which page should rank made rather than left to whichever the crawler encountered first.
Pagination and faceted navigation
How paginated and filtered sets are exposed: which pages are linked, which are canonical, whether parameters are crawlable, and what a crawler is allowed to discover. Faceted navigation is where a large store or directory generates unbounded URL space, and controlling it is a routing decision.
Template-level defect detection
Checking the templates that generate each page type for the defects that affect all of them: canonical values, structured data, headings, meta, internal linking, and whether the content is in the served HTML. Done per type, because the leverage is per type.
Query and rendering performance for discovery
The database and rendering cost behind a page, at the level it affects crawl behaviour: response time, stability, and the queries that make a template slow. Included here because a crawl-rate problem presents as a search problem and is fixed in the code.
Sitemaps and internal discovery
Sitemaps generated from the route source, and the internal linking that decides what a crawler reaches without them. On WordPress the internal link graph is frequently weaker than the site assumes, because navigation is menu-driven rather than content-driven.
Measurement by page type
Impressions, clicks and coverage segmented by page type rather than in aggregate, before and after. An estate-wide number hides a page type that improved and another that collapsed, and the segmentation is what makes the work evaluable.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Inventory the URL estate before deciding anything
Every class the platform generates, counted. The decisions that follow — what to index, what to canonicalise, what to link — are all relative to that inventory, and without it the work becomes a list of generic recommendations.
Decide the indexation model explicitly
For each class: findable, or not, and by what mechanism. Written down as a table, because the failure mode is inconsistency — one archive indexable and its near-twin not — and inconsistency is what produces the duplication the model was meant to prevent.
Implement in the template layer, not in settings
Canonicals, robots directives and structured data emitted from the templates that generate the page type, so the rule applies to every page of that type and to every page added later. A setting covers what the plugin author anticipated; a template covers what the site actually is.
Work by page type, not by URL
Findings are grouped by the template that produces them, because that is where the fix is and because it is where the leverage is. A single template defect corrected affects every page of the type, which is the opposite of the page-by-page work most audits imply.
Verify what the crawler receives
The served HTML, the response headers, the canonical and the rendered content. WordPress templates can emit a canonical that disagrees with the routing, and content can be present in the editor and absent from the output — both of which are only visible in what is delivered.
Measure per page type against a baseline
Segmented before and after, so a change that helped one type and damaged another is visible. Aggregate reporting is how an estate-wide improvement conceals a page type that lost half its visibility.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Audit
- Every URL class WordPress generates on this site, counted
- The indexation model, as a per-class decision table
- Duplicate and near-duplicate pairs, with the resolution chosen for each
- Template-level defects, grouped by the page type they affect
- Query and response cost behind each template
- Which sitemaps exist, what they contain and what they omit
Implementation
- Indexation decisions implemented in the template and filter layer
- Canonical, robots and structured data emitted per page type
- Pagination and faceted navigation controlled at the routing level
- Template defects corrected, affecting all pages of the type at once
- Sitemaps generated from the route source
- Query-level fixes where performance is constraining discovery
Verification
- Served HTML checked per page type, not sampled
- Indexation model compared against what the site actually serves
- Impressions, clicks and coverage segmented by page type, before and after
- Crawl rate and discovery timing where performance was a factor
- What remains and why, where a decision was to leave something alone
Architecture and technology
The URL classes WordPress generates
- Posts, pages and each custom post type archive
- Category, tag and custom taxonomy term archives
- Author archives, including accounts that never publish
- Date archives by year, month and day
- Attachment pages for every uploaded file
- Search result pages and their query parameters
- Pagination across every one of the above
- Any route registered by a plugin
Where WordPress and search engineering disagree
- WordPress treats every generated URL as a page; search treats most of them as duplicates
- WordPress generates paginated and filtered URLs freely; those can be unbounded in number
- WordPress resolves taxonomy and archive routes by default; each is an indexation decision
- WordPress's canonical handling is template-dependent; a wrong value affects a whole type
- WordPress renders templates through database queries; slow templates reduce crawl rate
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Template rendering is the performance constraint
Fixing WordPress speed without breaking the site.
WordPress speed optimisationThe platforms and the content model
Building and extending WordPress, including custom post types and taxonomies.
WordPress developmentThe pages exist and are not indexed
Coverage and crawl diagnosis when discovery is not the constraint.
Crawl and indexationThe problem predates WordPress
Templates, URL structure and a migration into the platform.
WordPress website migrationFrequently asked
Do we need a different SEO plugin?
Probably not, and that is usually not where the problem is. Plugins manage titles, meta descriptions, canonicals and sitemaps reasonably well for the page types their authors anticipated, and they have no opinion about whether a tag archive with two posts should be indexable, or whether your faceted product listing generates an unbounded URL space. The work on a WordPress site large enough to have a search problem is in the routing, the generated estate and the templates. We will audit what the existing plugin produces and say whether it is adequate for it.
Why are so many more pages indexed than we published?
Because WordPress generates far more URLs than anyone authors: a taxonomy archive for every term, an author archive for every account including ones that never post, a date archive for every period with content, an attachment page for every uploaded file, search result URLs, and pagination across all of them. On a site with ten thousand posts that generated estate is usually the majority of the indexed count. Whether each class should be findable is a decision — and the default answer the platform gives is yes to almost all of them, which is rarely right.
Should we noindex our tag and category pages?
Sometimes, and the answer depends on the content rather than on a rule. A category that is a genuine destination, linked from navigation, with its own description and enough distinct content, is a page worth ranking and noindexing it discards real visibility. A tag archive with four posts that duplicates the posts themselves is a near-duplicate that divides signals. The decision is per class and per site, and it has to agree with the internal linking and the canonicals — noindexing an archive that the site still links prominently leaves the crawler following a path the site has said leads nowhere useful.
Our site is slow. Is that a search problem?
It can be, in a way that does not show up as a page-experience metric. A slow or unstable response reduces how much a crawler is willing to fetch, which delays discovery of new content and re-evaluation of changed content. On a large site that effect is measurable and it presents as a discovery problem rather than a speed problem — new articles indexed days late, updates not reflected. Where that is the shape of the problem, the fix is in the database and the templates, which is why it is in scope here rather than left to performance work alone.
How do you avoid the usual generic WordPress SEO advice?
By working from this site's own inventory. Every finding here is a URL class, a page type or a template that exists on your site, with its own count attached, and every recommendation is a change to something specific. That is why the audit begins by enumerating the estate rather than by running a checklist — the same checklist produces the same advice for a ten-page site and a two-million-URL one, and it is wrong for at least one of them.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.