WordPress SEO Service

I begin with a crawl. I use Screaming Frog or similar to see how many pages are indexed and where the crawl budget is going. For a recent client, a WordPress site with 5,000 posts, the crawl revealed 12,000 URLs being crawled because of pagination, tag pages, and media attachment pages. I then clean up indexing: I disable archives for tags and categories if they are thin (the client had 300 tag pages, each with a single post). I set those to noindex. Next, I curate the XML sitemap. I exclude those thin pages and only include posts, core pages, and the main category structure. That sitemap was submitted via Search Console. After that, I fix canonicals. The site had multiple URLs for the same post: /post/, /post/?amp, and /post/ with a trailing slash inconsistency. I used a 301 redirect for the non-canonical versions and set the canonical tag to the preferred version. The duplicate content issue resolved within weeks. For speed, I optimise the database: clean transients, remove post revisions limit to 2, and use a lightweight caching plugin. I also switch to a fast hosting provider, as shared hosting was causing TTFB over 1.5 seconds. After these changes, Core Web Vitals improved from 'needs improvement' to 'good' for LCP and CLS. The client saw a 30% increase in organic traffic within three months. I would not rely solely on an SEO plugin for these fixes; plugins handle metadata but not structural problems. For multilingual sites, I configure [hreflang tags](/hreflang-tags/) manually because plugins often duplicate content. I also use [schema markup](/schema/) only on pages that can benefit from rich results, like recipes and reviews. That is the path I take.

Counter-argument: Some argue that you should focus on content first and let the plugin handle the technical side. I disagree, because content cannot rank if the site is not crawlable. For a site with 10,000 posts, even one misconfigured plugin can cause a crawl budget issue that delays indexing by weeks. I once spent a month undoing the damage caused by a "one-click SEO" plugin that generated 5,000 orphaned URLs. So I always audit first.

Edge case: If the site uses a custom post type that is not recognised by your SEO plugin, you need to manually add it to the sitemap. Check the wp_sitemaps_posts_query_args filter or use a developer to register it correctly.

Decision rule: When faced with a slow site, do not install a caching plugin until you have profiled the database. I measure query time with Query Monitor and reduce the number of plugins that run on every page load. I set a hard limit: no more than 15 plugins. That often forces a choice of which features are essential.

I see three common mistakes. First, indexing everything. I have seen sites with 50,000 indexed URLs where only 200 are useful. The rest are tag archives, media pages, and pagination. I block those in a [robots.txt](/robots-txt/) directive but also use noindex meta tags because robots.txt is a direction, not a block. Second, relying solely on plugins. A plugin like Yoast or SEOPress can set titles and sitemaps, but it cannot fix a broken redirect chain from a migration. You need to manually check [canonical tags](/canonical-tag/) and ensure every old URL has a [301 redirect](/301-redirect/) to the new one. Third, ignoring mobile performance. Google uses mobile-first indexing, so if your WordPress theme is heavy with unoptimised images and render-blocking JavaScript, your rankings will suffer. I test with Lighthouse and fix by deferring non-critical CSS and using responsive images. I also avoid lazy-loading plugins that break layout shifts; instead, I use native lazy loading (loading="lazy") which is supported in WordPress now.

Another watch-out: updating everything blindly. I do not update plugins on a live site without testing on a staging environment. An update to a caching plugin once broke the entire site for 24 hours. I schedule updates monthly and use a duplicate content check after each update to ensure nothing was duplicated.

Edge case: For sites with a large media library, attachment pages are a common source of thin content. I either disable them via a plugin or set them to noindex. But be careful: if you use a custom theme that relies on attachment page templates, disabling could break navigation. Test in staging.

Early in my career, I thought more indexed pages meant more traffic. I left tag and category archives indexable. For a client in the travel niche, the site had 2,000 categories, each with 2–3 posts. They were all indexed. In Google Search Console, the average position for those URLs was >50, and they were soaking up crawl budget. The core pages were being crawled once a month. After I deindexed 1,800 thin category pages, the core site pages started getting crawled daily. Traffic to those core pages increased by 40% within two months. That taught me to be aggressive with noindex.

I also tried to fix speed solely with front-end techniques. I used image compression and minification but ignored the database. For one site, the database had 50,000 post revisions and 10,000 unapproved comments. After cleaning that and switching to a faster PHP version, TTFB dropped from 2.5s to 0.8s. I now always start with database optimisation.

Another mistake: I assumed plugins would handle everything. I installed an SEO plugin and thought the sitemap and meta tags were done. But the plugin generated a sitemap that included 10,000 useless attachment URLs. I had to manually exclude those. I now prefer to control [sitemaps](/sitemap/) via a combination of the plugin and a filter.

I also misjudged the importance of [mobile-seo](/mobile-seo/) early on. I had a site that looked great on desktop but was terrible on mobile. Lighthouse mobile score was 30. After implementing responsive images and touch-friendly navigation, the site's mobile organic traffic increased 70% in three months. I now test mobile first.