Site icon Saad Raza SEO

WordPress Technical SEO Checklist: What to Fix First

Cover graphic for the technical SEO guide "WordPress Technical SEO Checklist: What to Fix First" by Saad Raza SEO

Quick answer

Fix WordPress technical SEO in severity order. Start with critical checks that can hide your site, such as the search engine visibility setting, robots rules and noindex tags. Then fix duplicate URLs, archives, redirects and broken paths, and leave theme weight and front-end hygiene for last. Check these before paying for an audit.

The HTTP Archive’s Web Almanac 2024 found canonical tags on 65 per cent of mobile pages and 69 per cent of desktop pages, a common tool for handling duplicate URLs.

Most WordPress technical SEO problems are caused by a handful of settings, plugins and leftovers that you can check yourself in an afternoon. This checklist groups those checks by severity, so you fix the things that can stop Google seeing your site first and leave the polish for later. Work through it before you pay anyone for an audit, and you will either solve the problem or know exactly what to ask for.

How to use this checklist

I have sorted every check into three levels. Critical items can remove pages from Google entirely or stop them being crawled. Important items waste crawling, split signals between duplicate URLs or confuse search engines about which page matters. Housekeeping items are worth doing but rarely the reason a site is struggling.

Work top to bottom. There is no point tuning image compression while a single tick box is telling search engines to ignore the whole site. For each item, note what you found, what you changed and the date. That log matters later, because if traffic moves you will want to know what changed and when.

You will need three things: admin access to WordPress, access to Google Search Console for the domain, and a browser where you are logged out (a private window works) so you see the site the way a visitor and a crawler do.

Critical: checks that can hide your whole site

1. The search engine visibility setting

WordPress has a reading setting that asks search engines not to index the site. Developers tick it during a build and forget to untick it at launch more often than anyone admits. Open the Reading settings and make sure the option discouraging search engines is unchecked. Then view the source of your homepage and search for noindex. If you find a robots meta tag with noindex on a page you want ranked, find out which setting or plugin is adding it.

2. Your robots.txt file

Visit yourdomain.com/robots.txt. You are looking for a Disallow: / line under User-agent: *, which blocks the entire site, or rules blocking folders that hold your real content. Many SEO plugins generate a virtual robots.txt, and a physical file uploaded to the server can override it, so check both. If the syntax looks unfamiliar, my guide to how robots.txt rules work explains each directive.

3. HTTPS and the preferred domain

Type every version of your address into the browser: with and without www, with http and https. All four should land on one single version with a permanent redirect. Then confirm the WordPress Address and Site Address in General settings both use that same version. A mismatch here causes redirect loops, mixed content warnings and duplicate versions of every page.

4. Staging sites that leaked into Google

Search Google for site: followed by likely staging addresses, such as staging.yourdomain.com or the temporary URL your host provides. If a copy of your site is indexed, it competes with the real one. Protect staging with a password at the server level, not just a noindex tag, and remove indexed copies through Search Console once that domain is verified.

Important: duplicates, archives and wasted crawling

5. Permalink structure

Check the Permalinks settings. A structure like /?p=123 or one that includes dates is harder to read and harder to change later. Use the post name structure for most sites. Warning: if your site is already established, changing permalinks changes every URL. Do not touch it without a full redirect plan, which is the same process I describe in the website migration SEO checklist.

6. Attachment pages

By default, WordPress can create a separate page for every image you upload. These pages usually contain nothing but the image and a title. Most SEO plugins have an option to redirect attachment URLs to the file itself or the parent post. Turn it on, then search site:yourdomain.com attachment to see if any are still indexed.

7. Tag, category, author and date archives

Every tag creates an archive page. A blog with hundreds of tags, each used once, creates hundreds of near-empty pages that list one post. Author archives on a single-author site duplicate the main blog. Date archives rarely serve anyone. Decide which archive types genuinely help readers and noindex or disable the rest. If you suspect this has already got out of hand, the guide to finding and removing index bloat walks through the clean-up.

8. Canonical tags

Open a few posts, view the source and find the rel="canonical" link. It should point to the clean, final URL of that same page. Common faults: canonicals pointing to the homepage, canonicals on paginated pages all pointing to page one, and two plugins each adding their own canonical. For the full logic, see what a canonical tag does.

9. XML sitemap contents

Find your sitemap (usually linked from robots.txt) and open it. It should list only pages you want indexed and that return a normal 200 status. Look for sitemaps of tags, attachments, test pages or a post type created by a plugin that nobody uses. Submit the sitemap in Search Console and compare what you submitted with what Google reports as indexed.

10. Plugin conflicts

Two SEO plugins active at once is a classic cause of duplicate titles, duplicate canonicals and two competing sitemaps. Page builders, caching plugins and security plugins can also add their own meta tags or rewrite URLs. List every active plugin and ask of each one: does this output anything in the page head, change URLs or touch redirects? Keep one plugin per job.

Important: redirects and broken paths

WordPress quietly creates redirects when you change a slug, and redirect plugins collect rules over the years. Over time you end up with chains (A goes to B, B goes to C) and rules pointing at pages that no longer exist.

  1. Export the rules from your redirect plugin, if you use one.
  2. Run a crawl of your site with any desktop crawler and filter for 3xx and 4xx responses.
  3. For every chain, update the first rule so it points straight at the final destination.
  4. For every internal link that hits a redirect, edit the link to point at the final URL directly.
  5. For 404s that receive links or traffic, redirect them to the closest relevant page. Leave genuinely dead pages as 404 or 410 rather than redirecting everything to the homepage.

That last point matters. Mass redirecting to the homepage is often treated by Google as a soft 404, so it gains you nothing and hides real errors from your reports.

Housekeeping: theme weight and front-end hygiene

These rarely cause a site to vanish, but they affect speed, crawl efficiency and how cleanly Google can read your pages.

A quick severity table for prioritising

Check Severity Typical symptom
Search engine visibility setting Critical Whole site missing from Google
robots.txt blocking Critical Pages reported as blocked by robots.txt
HTTPS and domain version Critical Duplicate versions, mixed content warnings
Staging leak Critical Second copy of the site in search results
Attachment and archive pages Important Large numbers of thin pages indexed
Canonical errors Important Google choosing a different canonical than you
Sitemap contents Important Submitted pages not indexed
Redirect chains Important Slow page loads, lost link value
Theme and builder bloat Housekeeping Poor Core Web Vitals reports

When the checklist is not enough

A checklist finds known patterns. It does not explain why a specific site behaves the way it does. If you have worked through everything above and Search Console still shows large numbers of pages crawled but not indexed, or rankings dropped after a change you cannot pin down, the issue is usually in how several of these items interact. For example, a sitemap listing tag pages that are also noindexed sends Google mixed instructions, and neither check on its own would flag it.

If you want the bigger picture of how crawling, rendering and indexing fit together, read how technical SEO works. And if you would rather have someone trace those interactions properly, that is what my technical SEO services are for.

Questions people ask about WordPress technical SEO

Do I need a premium SEO plugin to fix these issues?

No. Every item on this list can be handled with a free SEO plugin plus WordPress’s own settings. Premium versions add convenience features, but they do not fix configuration mistakes for you. One well-configured free plugin beats two premium ones fighting each other.

Should I noindex all tag pages on WordPress?

Not automatically. If a tag page collects several genuinely related posts and someone might search for that topic, it can be useful. Noindex tags that hold one or two posts or overlap heavily with a category. The decision is about value to a reader, not a blanket rule.

How often should I run this checklist?

Run the critical section after every theme change, plugin install that affects SEO, hosting move or redesign. Run the full list a few times a year on a stable site. The main point is to check after change, because that is when things break.

Can a caching plugin hurt my technical SEO?

It can if it serves stale pages with old canonicals or redirects, minifies scripts in a way that breaks rendering, or caches a logged-in version of a page. After configuring caching, view your pages logged out and check the source for the correct tags.

If you have run these checks and still are not sure what is holding your WordPress site back, I am happy to take a look. Request a free audit and I will tell you which issues are worth your time and which you can safely ignore.

Exit mobile version