Chapter 39: How to Do SEO on WordPress Sites

A WordPress dashboard on a laptop surrounded by plugin, speed and settings icons

Last updated: November 1, 2026.

When people hear “WordPress SEO,” the first thing that usually comes to mind is this:

Should we use Yoast or Rank Math?

I think WordPress SEO goes far beyond that.

WordPress gives you a good foundation, but because of the wrong theme, the wrong plugin, the wrong cache settings, unnecessary archive pages or technical problems that pile up over the years, a site can quietly become quite messy from an SEO point of view.

On a WordPress site, sometimes the problem isn’t the content. The problem is here:

  • Theme
  • Plugins
  • Slider
  • Cache
  • Category structure
  • Tags
  • Images
  • Canonical
  • Sitemap
  • Redirects
  • Updates

So WordPress SEO is partly the job of keeping the system under control.

1. Is WordPress a good foundation for SEO?

I think so. Used correctly, WordPress is a perfectly adequate foundation for SEO.

You can easily manage:

  • Title
  • Meta description
  • URL
  • Canonical
  • Sitemap
  • Robots settings
  • Schema
  • Images
  • Categories
  • Internal links
  • Redirects

But the fact that WordPress is powerful doesn’t mean every WordPress site is automatically SEO-friendly. The real difference comes from the settings and the site architecture.

2. Installing an SEO plugin is not doing SEO

Plugins like Yoast, Rank Math or All in One SEO make our work easier. But a plugin won’t answer the question “Should this page be indexed?” for you. It only applies the decision you make.

For example, setting a tag to noindex is technically very easy. But figuring out whether that tag page is actually valuable is an SEO decision.

That’s why:

An SEO plugin is a tool, not a strategy.

3. I started with All in One SEO, then moved to Yoast, and today we mostly use Rank Math

On the WordPress SEO side, I started with All in One SEO. After that I used Yoast SEO for a long time. Today we use Rank Math on most of our projects.

But what changed over the years was the plugin we used. Not the SEO logic.

With all three you can manage most of these basic areas:

  • Title
  • Meta description
  • Canonical
  • Sitemap
  • Robots settings
  • Schema

For me, the important question was never “Which plugin is better?” The more important question is:

“What are we doing with this plugin, and why?”

A plugin tells you, “I can set this category page to noindex.” But the answer to “Should this category actually be indexed?” is still up to you.

4. One of the first things to check after installing WordPress is the indexing setting

WordPress has a setting called Discourage search engines from indexing this site. It may have been turned on during development. Then someone may forget to turn it off when the site goes live.

The site works fine. The content is published. But you may be telling Google, “Please don’t index me if you can avoid it.”

That’s why this should be one of the first checks on every WordPress site that goes live.

5. Staging sites need to be checked separately

For example, a new site is being developed on staging.site.com. But on the staging environment there is:

  • No password
  • No noindex
  • No access restriction

Google discovers the site. Then the same content starts appearing on two different domains as the real site. In some cases, staging URLs even get indexed.

So development environments should ideally be:

  • Password protected
  • IP restricted
  • Closed to search engines

Relying only on the robots.txt file is not a good enough security approach for this.

6. A theme is not just design

A theme affects SEO more than we think. Because it can also affect:

  • HTML structure
  • Heading usage
  • Page speed
  • Amount of JavaScript
  • DOM size
  • Mobile experience
  • Image loading
  • Internal link structure

A theme that looks great can come with:

  • 4 different sliders
  • 20 JavaScript files
  • Huge CSS
  • Animations
  • Unused features
  • Page builder dependency

Then the SEO team tries to speed up the site.

When choosing a theme, I think you need to ask How does it work? as much as How does it look?

7. Sometimes a single slider is behind the whole speed problem

One of the performance problems we run into most often on WordPress sites is a poorly chosen slider.

What you need may actually be very simple:

  • A few images rotate in turn.
  • When the user clicks, they go to the related page.

But a very advanced slider plugin gets installed for this. The plugin can load along with it:

  • Animation systems
  • Video features
  • Effects
  • Layers
  • Fonts
  • JavaScript files
  • CSS files
  • Lots of features we never use

In the end, the visitor still sees three sliding images. But a small application is running in the background.

On some projects we’ve seen the PageSpeed score drop by around 20-30 points because of the slider alone. When the slider is removed or replaced with a simpler solution, you can get a big performance boost.

The lesson here is very clear to me:

The most advanced solution is not always the right solution.

If all we need is “the images rotate and go somewhere when clicked,” we may not need a system that loads dozens of features along with it.

On WordPress, a performance problem sometimes isn’t on the server or in 30 different plugins, but in a single poorly chosen component.

8. Is using a page builder an SEO problem?

Elementor, WPBakery, Divi and similar systems are not an SEO problem on their own. But used the wrong way, they can make a page heavy. A simple heading and image can produce dozens of nested HTML elements.

Add these on top, and the page gets heavier and heavier:

  • Animations
  • Slider
  • Pop-ups
  • Fonts
  • Third-party scripts

The point here is not to say “Don’t use a page builder.”

Don’t load what you don’t need.

9. The number of plugins is not the problem on its own

With WordPress you may hear hard rules like “If you use more than 20 plugins, your site will slow down.” I don’t think the number means much on its own. 5 badly written plugins can cause more problems than 30 well-built ones.

What you need to look at:

  • How many queries does it run?
  • Does it make external requests?
  • Does it load CSS / JS on every page?
  • Does it bloat the database?
  • Does it run unnecessary cron jobs?
  • Does it create a security problem?

So instead of How many plugins are there?, the better question is What are these plugins doing?

10. Don’t leave plugins you don’t use

You might think, “It’s deactivated anyway, it doesn’t do anything.” But unused plugins can create:

  • Security risk
  • Update overhead
  • Management clutter

Removing a plugin you don’t need is the cleaner approach.

11. You need to think through the category structure from the start

A blog is launched. Categories get added as content comes in. After a while, dozens of overlapping categories like these appear:

  • SEO
  • Technical SEO
  • SEO News
  • Google
  • Digital Marketing
  • Marketing
  • Internet

Some have 200 posts. Some have 2. Some serve almost the same purpose.

A category is not just a folder for content. Used correctly, it can be a strong SEO page.

That’s why the category structure:

Should be thought of as part of the site architecture.

12. Tags can bloat WordPress sites very easily

I think this is one of the most classic WordPress SEO problems.

On a news site or blog, 5-10 tags are created for every post. After a while you can end up with 10,000 posts but 40,000 tag pages. On top of that, some tags have only one post.

We end up opening tens of thousands of pages like these to Google:

  • Thin
  • Similar to each other
  • Offering the user very little value

Index bloat, which we discussed in Chapter 25, shows up here very often.

13. Should we turn off tags completely?

Not always. Well-managed tags can be valuable.

For example, if the “OpenAI” tag on a news site has hundreds of current and relevant articles, it can be a valuable archive for users. But creating a tag called “OpenAI CEO Statement” for a single news story may not make much sense.

My approach:

Before creating a tag, check whether it will turn into a real content cluster in the future.

14. Author archives should be checked too

On a single-author blog, the homepage and the author archive can show almost the same posts. In that case, you can question how much sense it makes to have the author archive indexed.

But on a multi-author news site, the author page can be a valuable page with:

  • Bio
  • Expertise
  • Articles
  • Social profiles

So again, there is no single answer.

You need to decide based on the site.

15. Date archives may be unnecessary on most sites

WordPress can automatically create these archives:

  • Year
  • Month
  • Day

For example, /2026/ and /2026/10/.

On some publications this can make sense. But on many corporate blogs, users have no need like “I want to see all content written in October 2026.”

Whether areas like these need to be indexed should be evaluated separately.

16. Don’t forget media / attachment pages

In WordPress, separate media pages can be created for uploaded images. For example, an image is product.jpg, but a separate URL for it like site.com/product/product-jpg/ can appear.

There is almost no content on the page. Just the image. We may not want pages like these indexed for no reason.

Most SEO plugins let you redirect them to the media file or to the related content. Since WordPress 6.4, these pages are turned off by default on new installs. But on older sites they may still be on.

17. Don’t set up the sitemap and forget about it

WordPress and SEO plugins have made creating a sitemap quite easy. But having a sitemap doesn’t mean everything is right.

You need to check:

  • Which content types are included?
  • Have categories been added?
  • Are tags in there?
  • Are noindex pages in the sitemap?
  • Do deleted URLs still show up?
  • Is the sitemap being updated?

In the news site example I described in Chapter 36, this is exactly where the problem was. To reduce server load, the developers had cached the sitemap for about 10 minutes.

A new story was published. But it only made it into the sitemap after the cache expired. For a news site, 10 minutes can be a very long time. When we cut the cache time down to seconds, the indexing delay was largely solved.

No SEO tool told us, “The problem is the sitemap cache time.” We found it by working backward from the problem.

18. Cache is very useful on WordPress, but set up wrong it can cause problems

WordPress sites can have more than one cache layer:

  • WP Rocket
  • LiteSpeed Cache
  • W3 Total Cache
  • Server cache
  • CDN

Used correctly, it’s very useful for speed. But sometimes:

  • New content doesn’t show up.
  • The old title stays.
  • The canonical doesn’t update.
  • The sitemap is delayed.
  • An old redirect keeps working.

Then on the SEO side we investigate, “We made the change, so why isn’t Google seeing it?” Sometimes the answer is just cache.

19. After clearing the cache, check that it was actually cleared

Clicking the “Purge Cache” button is not a check.

Look at the page’s source code. Open it in an incognito tab. If needed, check from a different device. If there’s a CDN, think about that too.

Something we said earlier about checklists comes up again here:

Done and verified are not the same thing.

In WordPress you can change the URL structure easily. For example, site.com/what-is-seo/ is much more meaningful than site.com/?p=123.

But on a site that has been running for years, suddenly changing the permalink structure because “it’ll be better for SEO” is risky. Thousands of URLs can change.

If you are going to make a change like this, think about these together:

  • Redirects
  • Canonical
  • Sitemap
  • Internal links
  • Search Console

Changing URLs is not a design setting.

It’s a migration.

21. Using the category in the URL is not required

In WordPress you can use site.com/seo/what-is-technical-seo/ or site.com/what-is-technical-seo/. There are scenarios where either can work.

What matters:

  • Consistency
  • Logical architecture
  • Avoiding unnecessary URL changes

Don’t expect an automatic SEO advantage just because the category is in the URL.

22. Don’t stop checking the canonical just because WordPress adds it automatically

SEO plugins make canonicals much easier. But these can break the canonical:

  • Theme
  • Plugins
  • Custom code
  • WooCommerce
  • Filter system

As happened with a real client of ours, a canonical problem had been fixed. Then another development was made. The same problem came back.

That’s why we don’t do an SEO audit once and leave it.

Having been fixed before doesn’t mean it’s correct today.

23. SEO checks after updates matter

WordPress itself gets updated. The theme gets updated. Plugins get updated. The PHP version changes. The server changes. All of these can affect the site.

After an update, you can check:

  • Canonical
  • Schema
  • Sitemap
  • Robots
  • Menu
  • Breadcrumb
  • Page structure
  • Analytics code

Sometimes an SEO problem doesn’t come from a change the SEO team made, but from a completely different development.

24. Even the analytics code can disappear

With one of our clients, we found that the Google Analytics code had been completely removed from the site. Nobody on the SEO side had removed it. It had disappeared during some other development.

No data was collected until the problem was noticed. You can’t bring back lost historical Analytics data afterward.

That’s why it’s important to put the presence of critical code on your checklist. On WordPress, things like this can happen after a theme change or a header edit.

25. Using Google Tag Manager can make things easier

Instead of scattering Analytics, Ads conversion and other measurement code directly across theme files, managing them centrally with Google Tag Manager can be more organized on many projects.

But using GTM doesn’t end the problem. If the container code disappears from the site, the whole system can still stop.

So:

You need to monitor your measurement setup too.

26. Images can be one of the biggest speed problems

An editor uploads an 8 MB photo from their phone. WordPress displays it at 700 pixels on the page. But the browser may still download a much bigger file than needed. When this repeats across thousands of posts, it’s a serious problem.

What to check:

  • Size
  • Format
  • Compression
  • Responsive images
  • Lazy loading
  • Width / height

But as we discussed in the e-commerce chapter:

Don’t ruin the quality of an image just to make it smaller.

With one of our wedding dress clients, the product images had been over-optimized. The site got faster. But when users zoomed in on mobile, the details looked bad. Sales suffered.

Let’s not break the business while raising the SEO score.

27. Using WebP or AVIF is not a solution on its own

Format matters. But converting a 5000 x 5000 pixel image to WebP and uploading it can still be unnecessary.

First, decide what we actually need:

  • Image dimensions
  • Quality
  • Where it will be used

Then think about the format.

28. Lazy loading should be used in the right place

Loading images below the fold later makes sense. But needlessly delaying the main image at the top of the page can hurt Largest Contentful Paint (LCP) performance. I covered LCP in Chapter 24.

So instead of saying “Lazy loading is good” and applying it to every image without control, you need to look at what should load and when.

29. The database can bloat over time

On sites that have been running for years, these can pile up:

  • Revisions
  • Transients
  • Tables from deleted plugins
  • Spam comments
  • Autosaves
  • Old metadata

You don’t have to clean every database all the time. But especially if there’s a serious performance problem, the database may need to be examined too.

Here, instead of installing a random “Database Cleaner” and deleting every table, it’s important to take a backup and move forward knowing what you’re doing.

30. The revision system is useful, but it can be controlled

WordPress keeps older versions of your content. That’s very useful. But on large sites that have been running for years and are constantly updated, thousands of revisions can build up.

If needed, the number of revisions can be limited. But this shouldn’t be thought of as “revisions hurt SEO.” It’s more of a database and operations management issue.

31. You may need to look at the WordPress cron system too

Some plugins can keep creating scheduled tasks. For example, tasks like:

  • Feeds
  • Sitemaps
  • Backups
  • Syncing
  • Email
  • Imports
  • APIs

On sites with high traffic or many integrations, WP-Cron can create load. At that point, other solutions like a real system cron can be considered.

This isn’t SEO work everyone needs to do directly. But on large WordPress projects it can be the source of a performance problem.

32. Hosting choice affects WordPress SEO

A very well-optimized site can still be slow on a bad server.

There are many factors on the hosting side:

  • CPU
  • RAM
  • Disk
  • PHP
  • Database
  • Server location
  • Cache
  • CDN

But again, there’s no such thing as “the most expensive hosting brings the best SEO.” You need infrastructure that fits the site’s needs.

33. Is a CDN a must for every WordPress site?

No. A small corporate site serving Turkey can run perfectly fast on a good server in a single location.

But a CDN can make a real difference if you have:

  • Global traffic
  • Lots of images
  • High traffic
  • Static assets

You should use tools because you need them. Not because “it’s on the SEO checklist.”

34. WooCommerce needs attention of its own

On the WordPress + WooCommerce side, things get more complex. Because many URL types can be created:

  • Product
  • Category
  • Tag
  • Attribute
  • Filter
  • Variation
  • Search
  • Cart
  • Account

Here, these topics we discussed in e-commerce SEO in Chapter 35 come directly into play:

  • Faceted navigation
  • Canonical
  • Index bloat
  • Product variations
  • Deleted products

Installing WooCommerce doesn’t make this structure correct by itself.

35. Indexing search results pages is usually unnecessary

WordPress’s own search system can create URLs like ?s=seo. We usually don’t want thousands of these indexed by Google.

In particular, bad actors can generate large numbers of meaningless search URLs by creating queries from outside. You should check how these areas are handled.

36. Parameterized URLs can multiply without you noticing

For example, these parameters can make the same content accessible from different URLs:

  • UTM
  • Filter
  • Sorting
  • Tracking
  • Campaign

WordPress alone may not be the cause. But combined with plugins, the number of URLs can grow very fast.

On large sites, it’s useful to track parameters through Search Console and crawl tools.

37. A 404 page shouldn’t just say “Page Not Found”

WordPress gives you a 404 page easily. But we can make it more useful for users. For example, you can offer paths like:

  • Search
  • Main categories
  • Popular content
  • Products

However, redirecting a URL that doesn’t exist to the homepage just so it isn’t a 404 is not right. If the old URL really has an equivalent, redirect it. If not, proper 404 / 410 behavior is normal.

38. Redirect plugins are very useful but can turn into a junkyard

Plugins like Redirection make our work easier. But over the years you can end up with:

  • Redirects that follow one another
  • Unnecessary rules
  • Redirect chains
  • Loops

For example, instead of A → B → C → D, A → D is cleaner if possible.

That’s why it helps to check the redirect list from time to time.

39. Breadcrumbs are very useful, especially on large WordPress sites

For example, “Home > Blog > SEO > Technical SEO” shows users where they are. It can also help Google understand the site structure.

Most SEO plugins support generating Breadcrumb Schema. But when the theme’s breadcrumb and the SEO plugin’s breadcrumb work together, problems like duplicate markup can appear. You need to check.

40. Multiple plugins can conflict on schema

The theme adds schema. The SEO plugin adds schema. The review plugin adds schema. WooCommerce adds another schema. Then the page can end up with three different Product schemas for the same product.

That’s why you need to look at “Is the right schema there?” as much as “Is there schema?”

41. Security looks like it’s outside SEO, but it isn’t

Because WordPress is so widespread, it gets attacked a lot. If the site is hacked:

  • Spam pages can be created.
  • Japanese content can get indexed.
  • Casino pages can be opened.
  • Redirects can be added.
  • Malicious code can be injected.

Then you have a serious SEO problem.

That’s why these shouldn’t be left outside SEO operations:

  • Updates
  • Strong passwords
  • 2FA
  • Backups
  • Security monitoring

42. Don’t make big changes without a backup

You’re going to update the theme. Switch plugins. Clean the database. Change the URL structure.

Backup first. Because sometimes, while trying to fix an SEO error, you can break the whole site.

Part of good SEO is also the ability to roll back.

43. An SEO checklist is a must on WordPress

I explained the importance of checklists in Chapter 34. WordPress is one of the best examples of this.

For example, after every major update you can check:

  • Does the site load?
  • Is Analytics working?
  • Is Search Console verification still in place?
  • Is robots correct?
  • Is the sitemap working?
  • Is the canonical correct?
  • Was noindex turned on by mistake?
  • Is the schema correct?
  • Are the homepage and key pages working?
  • Are redirects working?
  • Is the cache correct?
  • Does the mobile view look right?
  • Is there any major change on the Core Web Vitals side?

Because WordPress is a constantly changing system. You shouldn’t assume a setting that’s correct today will still be correct six months from now.

In short

The good thing about WordPress SEO is that it makes many things easy. The dangerous thing is the same.

With one plugin you can:

  • Open thousands of pages.
  • Set thousands of pages to noindex.
  • Change the URL structure.
  • Create redirects.
  • Change canonicals.
  • Set up a cache system.

So it’s a powerful system. But powerful tools, when used the wrong way, can also make problems grow fast.

I think the most important approach in WordPress SEO is:

As little complexity as possible, as much control as possible.

I started with All in One SEO, used Yoast, and today I mostly use Rank Math.

Tools change. Themes change. Plugins change. WordPress changes.

But here’s what doesn’t change:

We still have to decide what gets indexed, which URL lives on, which content is valuable and what we offer the user.

WordPress is just a very powerful tool for carrying those decisions out.

Previous: Chapter 38: How to Do SEO for Corporate and B2B Sites · Contents · Next: Chapter 40: SEO for Marketplaces, Classifieds and Large Database Sites

This chapter was first published in Turkish on X (October 19, 2026).