WordPress gets a lot of technical SEO right on its own. It outputs canonical tags, builds an XML sitemap, noindexes internal search results and redirects old post URLs when you change a slug, and it runs 40.2% of all websites on the Internet, so Google has had plenty of practice crawling it.
Most technical problems on WordPress sites come from what gets added on top. A plugin that noindexes a whole post type after an update, a security tool that blocks crawlers, a page builder that loads content with JavaScript, a staging site that ends up in Google, or a WooCommerce filter that creates thousands of URLs nobody asked for.
I’ve built nearly every one of my own sites on WordPress for about 15 years, and the checks below follow how much damage each problem can do, so the ones that can take a whole site out of Google come first.
The settings you check on every post (titles, headings, images and so on) are in my on-page SEO checklist, so I won’t repeat them here.
The short version
- Crawling first. Check robots.txt, and check that your host, CDN or security plugin isn’t blocking the crawlers you want, because robots.txt won’t show you that.
- Read the Page indexing report in Google Search Console once a month. It tells you what Google left out and why.
- Keep one sitemap, one version of the domain and one canonical URL for every page.
- Use 301 redirects, one hop at a time, and fix internal links that point to redirects or 404s.
- Speed matters less than most checklists suggest. Fix what’s clearly broken and move on.
- Add structured data that matches the page and that Google actually uses.
- WooCommerce stores need extra work on filter and sort URLs, add-to-cart links and product schema.
- Run the full checklist after any big change (new theme, migration, host move, redesign) and a lighter version every month.
What technical SEO covers
Technical SEO is everything that decides whether search engines can crawl your site, index the right pages and understand what they’re looking at.
That means robots.txt, sitemaps, redirects, canonical tags, status codes, site structure, speed, mobile rendering, HTTPS and structured data.
On-page SEO is what’s on each page, like the title tag, the headings and the content itself. The line between them is blurry (structured data and internal links show up on both lists), but a simple way to split them is that on-page SEO is done page by page, while technical SEO is mostly done once for the whole site and then monitored.
Technical SEO won’t make a weak page rank. What it does is make sure your good pages aren’t held back by something you can’t see from the front end, and on WordPress those problems are usually invisible until traffic drops.
The tools you need (all free)
You don’t need a paid tool for any of this on a small or medium site.
Google Search Console is the only tool that shows you what Google itself sees, so it comes first.
Screaming Frog crawls up to 500 URLs for free (a licence is €245 a year if you need more than that) and shows you status codes, redirects, canonicals, titles and noindex tags for every page.
Ahrefs Free, which used to be called Ahrefs Webmaster Tools, runs a full site audit on any site you verify. For speed, use PageSpeed Insights, and for schema, Google’s Rich Results Test.
The last tool is your browser. A lot of technical problems show up the moment you view the page source or open the site on your phone.
1. Make sure search engines can reach your pages
If a crawler can’t reach a page, nothing else on this list matters for that page, and crawling problems are the ones that can take out a whole site at once.
Check your robots.txt
WordPress creates a virtual robots.txt file for you. There’s no actual file on your server, WordPress just generates it when someone visits yoursite.com/robots.txt, and by default it looks like this (the sitemap line comes from WordPress’s own sitemap or from your SEO plugin).
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://yoursite.com/sitemap_index.xml
For a lot of WordPress sites that’s all you need. It keeps crawlers out of the admin area and still lets them load admin-ajax.php, which some themes and plugins use to load content on the front end.
To change it, use the robots.txt editor in your SEO plugin (Yoast, Rank Math and the others all have one) or upload a real robots.txt file to the root of your site, which overrides the virtual one. Either way, open yoursite.com/robots.txt afterwards and check what’s actually live.
The mistakes I’d look for are the ones copied from old tutorials. Don’t block /wp-content/ or /wp-includes/, because that’s where your CSS, JavaScript and images live. Google needs them to render the page the way visitors see it, and blocking /wp-content/uploads/ takes your images out of Google Images.
And don’t use robots.txt to keep pages out of Google.
Google’s own documentation says robots.txt is not a mechanism for keeping a page out of search results, and a blocked page can still get indexed (without a description) if other pages link to it. If you want a page out of Google, use a noindex tag and leave it crawlable, so Google can actually see the noindex.
Make sure your host or firewall isn’t blocking crawlers
This is the one I almost never see on technical SEO checklists. Hosting companies, CDNs like Cloudflare and security plugins like Wordfence all block bots they think are suspicious, and they don’t care what your robots.txt says.
Depending on the setup, a crawler might get a 403 error, a JavaScript challenge page (“checking your browser” or “one moment, please”) or a CAPTCHA instead of your content.
Googlebot is usually allowed through, because most of these tools verify it. SEO tools, AI crawlers and smaller search engines are often not. So your site can look perfectly fine in your browser and in Google, while ChatGPT’s crawler or your own Screaming Frog crawl gets a challenge page.
Two checks catch most of it. In Search Console, open Settings and then the Crawl Stats report, which shows how Google’s requests were answered and whether it hit availability problems. Then crawl the site with Screaming Frog, and if the crawl returns 403s or pages that all have the same title, your firewall is getting in the way. Whitelist the crawlers you want in your host’s bot protection, your CDN and your security plugin.
Decide what AI crawlers can see
AI tools now crawl the web for two different reasons, and you can control them separately. OpenAI, for example, uses OAI-SearchBot to find pages for ChatGPT search and GPTBot to collect content for training its models, and its documentation says you can allow the first while blocking the second.
Google works differently. Blocking Google-Extended controls whether your content is used for Gemini training and grounding, and Google says it has no effect on your inclusion or rankings in Google Search, so blocking it won’t hurt your SEO (I’d be wary of that, however).
What you decide is a business call. If you want your brand to show up and get cited in AI answers, don’t block the search crawlers. Plenty of site owners are making the call already. The 2025 Web Almanac found GPTBot named in the robots.txt of 4.5% of desktop sites, up sharply from the year before.
The catch is that robots.txt might not be where the decision gets made. In July 2025 Cloudflare started blocking AI crawlers by default for its customers, so if your site runs through Cloudflare, check its AI crawler settings too.
Make sure your content is in the HTML
Google renders JavaScript, so a page that builds its content with JavaScript can still get indexed. But rendering happens in a separate queue after crawling, and Google itself says in its JavaScript SEO guide that server-side rendering is still a great idea because not all bots can run JavaScript. When Vercel looked at AI crawler traffic across its network, it found that the crawlers from OpenAI, Anthropic, Meta and Perplexity didn’t render JavaScript at all, so if your content only appears after JavaScript runs, those crawlers see an empty page.
Most WordPress themes and page builders output normal HTML, so you’re usually fine.
The things to check are content loaded by sliders, “load more” buttons, some tab and review widgets, and product grids that fill in after the page loads.
Right-click the page, choose View Page Source (not Inspect), and search for a sentence from your content. If it’s in the source, crawlers can read it.
2. Get the right pages indexed
Crawling is about access. Indexing is about which pages Google decides to keep, and this is where WordPress sites leak.
Read the Page indexing report
The Page indexing report in Search Console lists every page Google knows about and splits it into indexed and not indexed, with a reason for each group. It’s one of the most useful technical SEO reports you have.
A lot of what’s in the not indexed list is fine. Pages with redirects, pages with a proper canonical pointing elsewhere, and pages you noindexed on purpose are supposed to be there. What you’re looking for are important pages in the wrong group.
The two statuses that confuse people most are “Discovered – currently not indexed” and “Crawled – currently not indexed.”
Discovered means Google found the URL but hasn’t crawled it yet, usually because it expected crawling to overload the site.
Crawled means Google fetched the page and decided not to index it for now, and that’s usually a quality or duplication signal. Resubmitting those pages doesn’t really help, either. What usually helps is making the page better, merging it with a similar page, or linking to it from pages that matter.
Hunt down accidental noindex tags
Noindex tags on WordPress come from more places than you’d think. The “Discourage search engines from indexing this site” setting noindexes the whole site (I cover it in the on-page checklist), your SEO plugin has noindex settings for every post type and taxonomy, individual posts can have their own noindex toggle, and some themes, membership plugins and page builders add their own.
The quickest way to see all of them is a Screaming Frog crawl, filtered to the Indexability column.
Every page marked non-indexable should be there on purpose. Do this after every SEO plugin switch and every major plugin update, because a changed default can noindex a whole post type overnight.
Keep staging sites out of Google
Most WordPress hosts give you a one-click staging copy of the site, and staging sites end up in Google more often than they should. A staging copy is a full duplicate of your site on another URL, so if Google finds it, it competes with your real site.
Google’s advice for anything you don’t want public is to password-protect it, and that’s the only method I’d trust for staging.
A noindex tag works too, but the classic mistake is pushing staging to live with “Discourage search engines” still ticked, which noindexes your real site. After every push from staging, check that setting and view the source of your homepage for a noindex tag.
Submitting URLs to Google
For a new or updated page, open the URL Inspection tool in Search Console, paste the URL and click Request Indexing. That’s the whole process, and for most sites it’s the only submission you’ll ever need besides the sitemap.
Keep your expectations realistic and be careful with plugins that promise instant indexing through Google’s Indexing API. The API only supports pages with JobPosting or livestream BroadcastEvent markup, so using it for blog posts or product pages is outside what Google built it for.
3. Keep one clean sitemap
WordPress has had a built-in XML sitemap since version 5.5, at /wp-sitemap.xml, and most SEO plugins switch it off and replace it with their own (Yoast and Rank Math use /sitemap_index.xml).
Problems start when both stay live, or when a plugin you’ve since removed left an old sitemap submitted in Search Console.
Open the sitemap you’ve submitted and check three things. It should list only pages you want indexed, which means no redirects, no 404s, no noindexed pages and no archives you’ve decided to keep out of Google. It should be the only sitemap submitted in Search Console. And it should include your important custom post types, because some plugins leave them out until you switch them on.
Don’t spend time on the priority and change frequency values some plugins let you set. Google ignores both. It does use the last modified date, but only if it’s consistently accurate, so avoid plugins or habits that bump the date on every post without changing anything.
4. Give every page one version
Search engines treat every different URL as a different page, so a site that works on several URLs has duplicates of itself.
Pick one domain version
Your site should work on one version of the domain, with or without www and always on https, and every other version should 301 redirect to it in a single hop.
Type all four combinations (http and https, with and without www) into your browser and check that each one lands on the same URL. Do the same for trailing slashes. WordPress redirects to whichever version matches your permalink settings, and some server or caching setups break that.
Check your canonical tags
A canonical tag tells Google which URL is the main version of a page.
WordPress core outputs one on posts and pages, and your SEO plugin takes over from there. On most pages it should point to the page itself.
An important thing to remember is that canonicals are a hint and not a rule. Google lists redirects and canonical tags as strong signals and sitemap inclusion as a weak one, and it can pick a different canonical if your signals disagree. So make them agree. The canonical URL should be the one in your sitemap, the one your internal links point to and the one that returns a 200 status code.
The crawl will show you the usual WordPress mistakes. Paginated archive pages (page 2, page 3) with a canonical pointing to page 1, pages with a canonical pointing to a URL that redirects, and two plugins each adding their own canonical tag.
Make sure nothing breaks your head section
This one is technical but worth thirty seconds. Browsers and crawlers expect only certain elements inside a page’s head section, and when they hit something that doesn’t belong there, like an image or a div, they treat the head as closed early.
Anything after that point, including your canonical, meta robots and hreflang tags, ends up in the body, where it doesn’t count.
The 2025 Web Almanac found invalid elements in the head of 10.1% of desktop pages. On WordPress the usual cause is a plugin or a tracking snippet that injects something into the head it shouldn’t.
View the page source and check that your title, canonical and meta robots tags come before anything that looks out of place.
5. Fix redirects and broken pages
When you delete a page or change a URL, 301 redirect the old URL to the closest matching page. A 301 tells Google the move is permanent. With a 302, Google follows the redirect but doesn’t treat it as a signal that the new URL should become canonical, so use 302s only for moves that really are temporary. Rank Math has a redirect manager built in, and the free Redirection plugin works with any setup.
Redirect chains build up over years of changes, one redirect pointing to another that points to a third. Google follows up to 10 redirect hops, so chains rarely break anything outright, but each hop slows crawling and users down.
Point every old URL straight to its final destination, and update internal links so they point to the final URL instead of going through a redirect.
Another point of confusion I see all the time are 404 pages. 404 errors on their own don’t hurt your site. Pages that are gone should return a 404, and they don’t necessarily require a redirect. The ones worth redirecting are 404s that still get backlinks or traffic, and Screaming Frog (for internal links) plus Ahrefs Free (for backlinks) will find them.
Also watch for soft 404s in Search Console, which are pages that return a 200 status but look empty or like an error to Google, such as empty category pages or search results with nothing in them.
6. Keep important pages close to the homepage
Pages that sit deep in the site, or that no other page links to, get crawled less and rank worse.
Check the crawl depth column in Screaming Frog and make sure your important pages are within three or four clicks of the homepage, and look for orphan pages, which are pages in your sitemap that no other page links to.
Breadcrumbs help too, and most SEO plugins and themes can add them with BreadcrumbList schema included. My internal linking guide covers how to fix structure on a WordPress site properly.
7. Fix speed problems that actually matter
Run your main page templates (homepage, a post, a page, a product if you have them) through PageSpeed Insights and look at the field data at the top, which comes from real Chrome users. The Core Web Vitals report in Search Console shows the same data for your whole site, grouped into similar pages.
On WordPress, slow sites almost always come down to the same few causes. Cheap shared hosting, no page caching, heavy page builders and sliders at the top of the page, plugins that load scripts on every page even where they’re not used, and huge images. Fix those and most sites pass.
Despite what many people believe, site speed is a tie-breaker at best. Do not burn a week chasing a score of 100.
8. Check the site on mobile
Google now indexes the web with its smartphone crawler. The move to mobile-first indexing finished in July 2024, and sites that don’t work on mobile at all risk dropping out of the index. So for Google, the mobile version of your page is the page.
Almost every WordPress theme is responsive, so the site itself is rarely the problem. The problem is content that’s hidden or removed on mobile. Some themes and page builders let you hide sections by device, and Google’s mobile-first indexing guide is clear that your mobile site should contain the same content as the desktop one.
If your builder removes a section on mobile rather than just restyling it, Google won’t see that section at all.
Beyond that, mobile SEO is about the basics you’d notice yourself on a phone, like text you can read without zooming, buttons that aren’t crammed together, no popups covering the content and pages that load in a reasonable time on mobile data. Open your key pages on your phone and use them like a visitor would.
9. Keep the site secure
HTTPS is table stakes. Google made it a ranking signal back in 2014, browsers flag sites without it, and every decent host offers free SSL certificates.
After moving to HTTPS, crawl the site for mixed content (images, scripts or stylesheets still loading over http) and for internal links still pointing to http URLs. Both are usually hard-coded in old posts or theme settings.
Security matters for SEO in a less obvious way too. Hacked WordPress sites are often used to inject spam pages (fake product pages in other languages are a classic) that you won’t see unless you look for them.
Keep WordPress, themes and plugins updated, remove plugins you don’t use, and check Search Console’s Security issues report. A site:yoursite.com search in Google now and then also shows you pages you didn’t know existed.
10. Use structured data that does something
Structured data, or schema markup, is code that describes what’s on a page in a format search engines can read without guessing. Google supports a specific list of types in its search gallery, and only those can change how your page looks in the results.
These are the types worth having on a typical WordPress site, and when each one applies.
| Schema type | Use it on | What it can do in Google |
| Organization or LocalBusiness | Homepage, contact page | Helps Google connect your site to your business details |
| Article or BlogPosting | Blog posts | Clarifies the headline, author and dates |
| BreadcrumbList | Every page with breadcrumbs | Shows the breadcrumb path in desktop results (not on mobile since 2025) |
| Product (with offers and reviews) | Product pages | Price, availability and ratings in results |
| Review snippet | Real review pages | Star ratings, within Google’s rules |
| Recipe, Event, JobPosting, VideoObject | Pages that really are that type | Rich results for each type |
Your SEO plugin usually adds Organization, Article or WebPage and BreadcrumbList for you. For most blogs and service businesses, that’s enough.
You won’t write it by hand on WordPress, but knowing what it looks like makes it easier to check what your plugins output. If you run a local business, my guide to local SEO on WordPress covers the rest of the setup.
The rules that matter are simple. Only mark up what’s visible on the page, since Google’s structured data guidelines say not to mark up content hidden from readers, and don’t add types that don’t fit just to chase stars in the results.
On WordPress the most common schema problem is duplication. Your theme, your SEO plugin, a schema plugin and WooCommerce can each output their own markup, and you end up with two Product or two Organization entries that disagree. Run your main templates through the Rich Results Test, and use the Schema Markup Validator to see everything on the page, including types Google doesn’t show rich results for.
11. Set up hreflang if you run a multilingual site
If your site has several language or country versions, hreflang tags tell Google which version to show to which users. Multilingual plugins like WPML and Polylang add them for you, so the job is mostly checking that every version links to every other version (including itself) and that the URLs in the tags return a 200. Google’s localized versions guide covers the rules. If your site is in one language, skip this.
WooCommerce stores need a few extra checks
WooCommerce adds a store’s worth of URLs to WordPress, and most of the extra technical work comes from URLs nobody meant to create.
| URL type | Example | What to do |
| Cart, checkout, my account | /cart/, /checkout/ | Nothing. WooCommerce already noindexes them. |
| Sort order | /shop/?orderby=price | Block in robots.txt |
| Layered navigation filters | /shop/?filter_color=red | Block in robots.txt, or build real category pages for filters people search for |
| Price filters | /shop/?min_price=10 | Block in robots.txt |
| Add-to-cart links | /shop/?add-to-cart=123 | Block in robots.txt |
| Paginated category pages | /shop/page/2/ | Keep crawlable, each page with its own canonical |
| Product variations | /product/shirt/?attribute_pa_color=blue | Leave them, they canonicalize to the main product |
WooCommerce adds a noindex to the cart, checkout and account pages on its own through a function called wc_page_no_robots, so those don’t need any work.
Filter and sort URLs are the big one. Every combination of filters creates a new URL, so even a store with a few hundred products can end up with thousands of near-duplicate pages.
Google’s faceted navigation guide recommends blocking these in robots.txt when you don’t need them indexed. The add-to-cart links on product listings are worth blocking for the same reason, since crawlers follow them like any other link.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*add-to-cart=
Disallow: /*orderby=
Disallow: /*filter_
Disallow: /*min_price=
Disallow: /*max_price=
One warning before you add these. If some of those URLs are already indexed, blocking them in robots.txt stops Google from seeing any noindex tag on them, so they can linger in the index.
In that case, noindex them first, wait for them to drop out, then block them. And if a filter combination is something people actually search for (like “red linen dresses”), don’t rely on a filter URL at all.
Build it as a proper category page with its own content, which I properly explain in my eCommerce keyword research guide.
For paginated category pages, Google no longer uses rel=next and rel=prev tags, and it says each page in the sequence should have its own canonical rather than pointing back to page one. Leave them crawlable, because that’s how Google reaches the products listed deeper in the category.
For products that are temporarily out of stock, keep the page live and let the Product schema show the availability. For products that are gone for good, redirect to the closest replacement or the parent category if there’s a sensible match, and let the page return a 404 if there isn’t.
Last, check your product schema for duplicates. WooCommerce outputs its own Product markup, and SEO and schema plugins often add theirs. The better ones replace WooCommerce’s version instead of adding a second one, but not all of them do, so run a product page through the Rich Results Test and make sure you see one Product entry with the right price and availability.
How often to run this checklist
You don’t need to run the whole thing every month. What matters is running it after the changes that break things.
| When | What to check |
| After a new theme, migration, host move or redesign | The full checklist, plus a full crawl compared to the crawl before the change |
| After switching or updating an SEO, security or caching plugin | Robots.txt, sitemap, noindex tags, canonicals and a quick crawl |
| Every month | Page indexing report, Crawl Stats, Core Web Vitals and Security issues in Search Console |
| Every quarter | A full Screaming Frog crawl or Ahrefs Free site audit |
Migrations deserve extra care because they can change a lot of URLs at once. Take a full crawl before you migrate, keep it, and compare it with a crawl right after launch so you can see every URL that lost its redirect, its canonical or its content.
What you can ignore
Plenty of technical SEO advice doesn’t apply to a normal WordPress site.
Crawl budget is the big one. Google’s own crawl budget guide says it’s meant for sites with over a million pages, or over 10,000 pages that change daily.
If your site has a few hundred pages, Google can crawl all of them and crawl budget isn’t your problem, even if a tool warns you about it.
Also safe to ignore are sitemap priority and change frequency values, rel=next and rel=prev tags, HTML validation errors outside the head section, “text to HTML ratio” warnings, and a PageSpeed score that isn’t perfect. None of them move rankings for a site that gets everything else on this list right.
If you want more practical guides like this one, Built to Rank is my occasional newsletter on what’s actually working in SEO. It only goes out when I have something worth sending.
A couple more questions
Where is the robots.txt file in WordPress?
Unless you’ve uploaded one, there isn’t an actual file. WordPress generates a virtual robots.txt when someone visits yoursite.com/robots.txt. You can edit it through your SEO plugin’s robots.txt editor, or upload your own robots.txt file to the site’s root folder, which replaces the virtual one.
How do I submit my WordPress site to Google?
Verify your site in Google Search Console, submit your sitemap under Sitemaps, and use the URL Inspection tool to request indexing for individual pages. Google will find and crawl the rest through your sitemap and internal links.
Do I need a technical SEO plugin?
One SEO plugin (Yoast, Rank Math, All in One SEO, SEOPress or The SEO Framework) covers the technical settings WordPress doesn’t handle on its own, like noindex controls, the sitemap, redirects in some plugins and basic schema. Add a caching plugin if your host doesn’t cache pages for you.