Technical SEO on WordPress: Fixing What the Platform Gets Wrong
WordPress ships several SEO problems as defaults: a page per uploaded image, archives with nothing on them, pagination that splits signals, and two sitemaps that disagree. Each has a specific fix.
On This Page
Somebody uploads forty photographs to a gallery post. WordPress creates forty new URLs behind them, one per file, each holding a single image, a title lifted from the filename and nothing else. Nobody linked to them deliberately. Nobody asked for them. They are in the sitemap by Friday, and a month later they are the reason a site with ninety real pages reports several hundred indexed URLs and nobody can explain the gap.
Most WordPress technical SEO work is not clever, and very little of it is about plugins. It is about reversing decisions the platform made when it was a blogging tool: decisions that were reasonable then and are wrong for a business site now. Attachment pages. Author and date archives. Pagination that quietly cancels itself. Taxonomies serving the same post at four paths. Two sitemaps disagreeing about which of those URLs you meant to publish.
The position worth taking is that none of these are bugs, so none of them are fixed by updating. They are defaults, and a default changes only when somebody decides it should. If you have just taken over an install, the inventory comes before the fixes, because a good share of the URLs on that list will turn out to belong to templates nobody knew were public.
Why the defaults are wrong for your site
WordPress publishes generously. Almost anything that can have a URL gets one: every uploaded file, every author, every month, every tag, every phrase typed into the search box. That generosity made sense for a personal blog where archives were the navigation and the author was the point. It makes considerably less sense for a company site with twelve service pages, a careers page and a blog that publishes twice a month.
The cost is rarely a penalty. Search engines are good at ignoring low-value pages, and they do. The cost is quieter than that: a crawler spends its budget on URLs you would not defend, your reporting fills with pages nobody meant to publish, and the templates you actually care about compete with near-copies of themselves. It also makes every later diagnosis harder, because you can no longer tell ignored from not found in a coverage report full of noise.
The usual signs, in roughly the order teams notice them:
- Indexed URL counts far exceeding the number of pages anyone on the team can name.
- Coverage reports dominated by archive paths rather than by the pages the business sells from.
- Internal site search results, the /?s= URLs, appearing in the index.
- Two XML sitemaps reachable at the same time, listing different sets of URLs.
- One blog post available at three addresses depending on which category you arrived through.
- Image filenames showing up as page titles in search results.
None of this is an emergency. That is exactly why it survives for years. Each item is small enough to defer and none of them shout, so they accumulate until a redesign or a migration forces somebody to look at the full URL list and find it four times longer than expected.
Attachment pages: a URL for every upload
This is the first thing to fix on almost every install, because it is the highest volume and the easiest to reverse.
Why every upload gets a page
Media in WordPress is a post type. An attachment behaves like any other post: it has an ID, a title, a slug, a permalink and a template that renders it. Upload a file called hero-shot-final-v3.jpg and you have published a page whose heading is Hero Shot Final V3, whose body is one image, and whose only inbound link is a thumbnail in a gallery block.
On a brochure site this is untidy. On a WooCommerce catalogue it is structural, because every product gallery image becomes a page, and a catalogue with several images per product produces more attachment URLs than product URLs. Those pages carry the product name in the title, so they also compete, weakly and pointlessly, with the product page itself.
The fix, and the wrong version of it
Redirect them, do not merely hide them. A 301 from the attachment URL to its parent post is the correct response, because the URLs are already linked from galleries and will keep being requested by crawlers and by anyone who clicked an image. Where an attachment has no parent, return 410 rather than 404: it says the removal was deliberate. Every mainstream SEO plugin carries a toggle for this, usually labelled something close to "redirect attachment URLs", and it is one of the few plugin settings genuinely worth the dependency.
The wrong version is adding noindex and stopping there. That leaves thousands of live URLs which must be crawled before the directive can be read, so you keep the crawl cost and lose the pages anyway. Whichever route you take, crawl the site afterwards and confirm the attachment paths now respond with a redirect rather than a 200. Plugins change these behaviours between major versions, and a setting that worked last year is not evidence that it works today.
Archives with nothing on them
WordPress generates four archive families out of the box: author, date, category and tag. Most sites need one of them, tolerate a second, and publish all four.
Author archives
On a single-author site the author archive is a straight copy of the blog index with a different heading. There is nothing on it that is not somewhere better. Disable it, or redirect it to the blog. On a multi-author site the calculation reverses: if you publish under named writers with real expertise, the author archive is where that claim is demonstrated, and it deserves a proper page with a biography rather than a bare post list.
Date archives
Monthly and yearly archives slice the same posts by a dimension almost nobody browses by. They existed because early blogs used them as navigation. Unless your analytics show readers genuinely using them, and for most business sites they do not, switch them off. If something in the theme depends on them, noindex the templates and remove them from the sitemap rather than leaving them half-published.
Tag sprawl
Tags are where this gets worst, because tagging feels free at the moment of writing. A term invented once, applied to one post, produces an archive page listing exactly one post, with a title that reads like a topic hub and content that is a single link. Multiply by two years of publishing. The rule we apply is simple: a taxonomy term earns its URL when a reader would plausibly want everything under it, and when there is enough under it to be worth arriving at. Everything else is a note to yourself, not a page.
Blocking a path in robots.txt stops the crawl, not the indexing: a URL can still appear in results on the strength of links pointing at it, because the crawler was never allowed to read the noindex you added. If you want a page out, let it be crawled and let it say noindex. If you want it gone permanently, redirect it or return 410. Using both together is the most common self-inflicted wound in this whole area.
Pagination: page 2 is not a duplicate, and not a destination
The instruction to pair paginated pages with next and previous link relations was retired years ago, and a lot of WordPress configuration never caught up. What replaced it is less exciting and more forgiving: each paginated page is its own URL, it should canonicalise to itself, and it should stay crawlable so the posts that live only on page four remain reachable. That is the whole of it. Most of the damage in this area comes from teams trying to do something cleverer, which is why it belongs in an ordinary technical SEO pass rather than in a strategy document.
The classic misconfiguration is a canonical tag on every paginated page pointing back at page one. It looks tidy. What it actually says is that pages two onward are duplicates that need not be considered, which quietly strands every post that is only linked from them. On a blog with a long back catalogue, that can remove years of writing from consideration without anything appearing to break.
The second failure is the infinite-scroll or load-more pattern that never produces a real URL. If the only way to reach the twentieth post is to run JavaScript and scroll, then the archive is not a path to that post, and the post depends entirely on internal links from elsewhere. Keep numbered pagination available even when the visible interface prefers a button, and give each page a title that differs from the first, so a results listing does not show the same title repeated.
One post, four URLs
Categories and tags overlap by design in WordPress, and most teams use them interchangeably within about a fortnight of launch. A post filed under three categories and five tags appears on eight archive pages. Add a custom taxonomy for a content type somebody built two years ago, plus the search results template, and the same article is reachable through a dozen routes, each of which reproduces its title and excerpt.
The fix is editorial before it is technical. Decide what a category means, decide that a post gets exactly one, and treat tags as a filtering convenience that does not need public archives at all. If you registered custom post types or taxonomies, revisit whether they were registered as publicly queryable on purpose or because that was the value in the tutorial. Where the duplication runs across brands rather than within one install, the question moves up a level and becomes a multisite or separate installs decision instead.
One caveat worth stating plainly: category archives are not automatically waste. On a publication with genuine depth in a subject, a category archive with an introduction, a curated order and a reason to exist is a legitimate hub and often outranks the individual posts under it. The distinction is whether somebody wrote it or whether the platform generated it. Generated lists are the problem, not archives as a concept.
Two sitemaps, and neither is right
Since WordPress began generating its own XML sitemap, most sites running an SEO plugin have had two. One at wp-sitemap.xml from core, one at the plugin path, both reachable, both claiming to describe the site. They rarely agree, because the plugin knows about your noindex settings and core does not.
Pick one generator and mean it
Turn the other one off rather than hoping it is ignored. Core exposes a filter for exactly this, and every plugin that generates a sitemap disables core automatically or offers a switch to do so. Then make robots.txt reference the surviving sitemap, and only that one. A stale reference in robots.txt to a sitemap you retired is a small thing that keeps producing confusing crawl behaviour long after the change.
What belongs in it
A sitemap is a list of the URLs you want indexed, not the URLs that exist. Only canonical, indexable, 200-status pages belong in it. A noindex URL inside a sitemap is a contradiction, and a crawler resolves contradictions in whichever direction costs you something. Redirects, parameter variants, paginated archives you have chosen to keep out, and anything behind a login all come out.
While you are there, look at the last-modified dates. A plugin that stamps today onto every URL on every publish tells search engines that four hundred pages changed when one did. That is not a penalty either, but it is a signal you have deliberately made useless, and you cannot get it back when you need it.
The order to do this in
Here is the whole set, with what a crawler currently sees and what should replace it.
| Default | What a crawler sees | The fix |
|---|---|---|
| Attachment pages | A URL per uploaded file, one image, no content | 301 to the parent post; 410 where there is none |
| Author archives | A copy of the blog index | Disable on single-author sites; write them properly otherwise |
| Date archives | The same posts sliced by month and year | Disable unless readers demonstrably use them |
| Tag archives | Pages listing a single post each | Prune terms; noindex the thin ones that must stay |
| Paginated archives | Page two canonicalised back to page one | Self-canonical every page, keep numbered links crawlable |
| Overlapping taxonomies | One post reachable at several paths | One primary term per post; unregister unused taxonomies |
| Two sitemaps | Conflicting claims about the same site | One generator, referenced once in robots.txt |
| Search result pages | Query URLs crawled and sometimes indexed | noindex the template and keep it out of the sitemap |
Sequence matters more than speed. This is the order we would run it:
- Build the URL inventory first. Crawl the site, export what search engines report, and pull the sitemap. Three lists, one spreadsheet. Anything that appears in one and not the others is already telling you something.
- Decide which templates should be public at all. This is a decision about the site rather than about search, and it takes an hour with somebody who knows what the pages are for.
- Remove or redirect before you noindex. If a URL should never have existed, take it out of circulation properly. noindex is for pages that serve readers but should not compete in search.
- Fix the internal links pointing at what you removed. A redirect is a repair, not a plan. Gallery blocks, menus and older posts should point at the surviving URLs directly.
- Settle the sitemap last. It should describe the site you now have, not the one you are halfway through changing. Resubmit once, when the rest is done.
- Then wait, and watch the right numbers. Index counts fall first, and that is the intended outcome. Judge the work on the pages you kept, over weeks, never on the total.
Removing several thousand URLs makes a graph go down. If nobody warned the person who reads that graph, you will spend a fortnight defending the best work you did that quarter. Write down, in advance, that indexed pages should fall and that the real measure is impressions and entrances on the pages you chose to keep.
What none of this fixes
An honest limit: everything above is hygiene. It removes drag. It does not create demand, it does not make a slow site fast, and it will not lift a page that has nothing to say. A tidy URL structure around thin content produces tidy thin content. If the pages you kept are not better than the alternatives already ranking, the cleanup buys you clarity in your reporting and very little else.
There is a second cost worth naming. Most of these toggles live inside a plugin, which means your crawl directives, your canonicals and your sitemap are now owned by code you did not write and do not review. That is a dependency like any other, and it deserves the same scrutiny as anything else running on the site. The related habit of stacking tools until nobody can say which one sets the canonical is how installs end up with two of everything, in the same way that third-party scripts accumulate until a single page loads four analytics libraries.
Every URL you publish is a claim that it deserves to exist. WordPress makes that claim on your behalf, several thousand times, without asking.
The version of this that ages well is a written record of which templates are public and why, kept next to the site rather than in somebody’s memory. It takes a page. It survives staff changes, plugin updates and the next agency, all three of which will otherwise re-enable something you switched off for a good reason.
Where we would start on Monday
On a typical business site: attachment pages first, because the volume is large and the change is reversible. Author and date archives second, because they are two switches. Tags third, because pruning them needs judgement and somebody has to make it. Sitemap last. If you want that turned into a written list against your own URLs, that is what an SEO audit is for, and the output should be a list of decisions rather than a score out of a hundred.
The condition under which this advice reverses: if a rebuild or a platform move is already funded and scheduled, do not spend three weeks tidying URLs you are about to retire. Fold the decisions into the migration instead, where the redirect map has to be written anyway. The single exception is attachment pages, which are worth removing even the week before a move, because otherwise they enter the new site’s redirect map and live there for years.
It is also fair to ask why a platform should be generating these URLs at all. Systems that build pages from structured content publish what you defined and nothing more: a workspace like Acrosite generates the files, commits them to GitHub and triggers the configured deployment, so there is no attachment template to disable because no such post type was ever invented. Our parent company has written about the same trade-off from the editorial side, in where drafts live and what stops them.
That is not an argument for leaving WordPress. It runs an enormous share of the web perfectly well, and a disciplined install beats a fashionable rebuild most of the time. It is an argument for treating the defaults as choices you own, revisiting them on a schedule as part of ongoing maintenance, and saying so out loud when they drift back. If you would rather have another pair of eyes on the URL list, send us what you are running.
Common questions.
What are WordPress attachment pages and should I disable them?
Attachment pages are the standalone URLs WordPress creates for every uploaded media file, each showing a single image with a title taken from the filename. They should be redirected rather than left live, because they add crawlable URLs with no content and can compete with the pages that embed them. Redirect each attachment URL to its parent post, and return 410 for orphaned files.
Should author archives be noindexed on a WordPress site?
On a single-author site, yes, or disable the template entirely, because the author archive duplicates the blog index without adding anything a reader cannot already reach. On a multi-author publication the answer flips: the author archive is where writer expertise is demonstrated, so it should carry a real biography, credentials and a curated post list rather than being suppressed.
Does WordPress still need an SEO plugin for its XML sitemap?
No, WordPress generates a sitemap on its own, but a site should still run only one generator. The core sitemap does not know about noindex settings applied by a plugin, so running both produces two files that disagree about which URLs you want indexed. Choose one, disable the other, and reference the survivor from robots.txt.
How should paginated blog archives be canonicalised?
Each paginated page should canonicalise to itself, not back to page one. Pointing every page at the first tells search engines that later pages are duplicates worth ignoring, which strands any post reachable only from them. Keep numbered pagination links crawlable in the HTML, and give each page a title that differs from the first.
Will removing indexed pages hurt my search traffic?
Removing genuinely low-value URLs rarely costs meaningful traffic, but it does make index counts drop, which looks alarming if nobody expected it. Check first whether any of the pages receive entrances or have external links pointing at them. Redirect those few to a relevant surviving page instead of deleting them, and judge the outcome on the pages you kept.
Is robots.txt enough to keep a page out of search results?
No. Disallowing a path in robots.txt prevents crawling, not indexing, and a blocked URL can still appear in results on the strength of links pointing to it. To remove a page, allow it to be crawled and serve a noindex directive, or remove it properly with a redirect or a 410 response. Never apply both at once.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.