WordPress SEO Strategy: What the Yoast Plugin Can’t Measure

Every light in the Yoast SEO plugin is green and the page still isn’t ranking. That’s the moment a WordPress SEO strategy stops being a plugin setting and starts being an infrastructure question. The plugin grades what’s in the editor. A WordPress SEO strategy has to cover the five layers underneath it: the server, WordPress core, the theme, the URLs WordPress generates on its own, and the front end your visitors actually load.

One note on sourcing before any of that. Every number, date and version below comes from a primary source, either Google’s documentation, WordPress.org, or the vendor’s own pages, and vendor claims stay labeled as vendor claims, because a plugin company describing its own plugin is marketing rather than evidence. We won’t re-caveat it in every paragraph.

Yoast SEO is the most installed SEO plugin in WordPress by a wide margin, and any WordPress SEO strategy written in 2026 has to start by being fair to it. WordPress.org’s plugin directory lists it at 10 million-plus active installs, version 28.3, last updated August 18, 2026, rated 4.8 out of 5 across 27,818 ratings. Yoast’s own marketing claims 13 million sites with no published methodology behind the larger figure, so the repository number is the one worth quoting.

Yoast makes the case against its own scoreboard, on its own site. On the page describing what it deliberately avoids building, the vendor writes that “SEO scores are opinionated and arbitrary” (opens in new tab), because ranking factors aren’t public and nobody outside the algorithms knows how they interact. The same page explains why the checks carry no weighting: Yoast says it won’t tell you whether one item matters more than another, “simply because we can’t.”

Yoast also publishes a troubleshooting article for exactly this situation, headed with twelve reasons an optimized page still isn’t showing up. Read that list as a specification and it describes work the plugin doesn’t do.

That’s the vendor’s own account of what decides rankings, and every item on it sits outside the editor. Most of a WordPress SEO strategy is the work on that list.

The plugin still earns its install count. Automated meta tags, canonical URLs, XML sitemaps, breadcrumbs and schema output are real work you’d otherwise hand-roll, and Yoast ships all of it in the free version. Yoast even tells you not to chase a perfect score: its guidance on using the content analysis says posts on yoast.com “often have a few orange lights and sometimes even one or two red ones.”

Knowing what the checks do mechanically changes how much weight they get in a WordPress SEO strategy. Yoast documents eighteen SEO checks, two of which, keyphrase distribution and stale cornerstone content, are Premium, so a free install actually runs sixteen: keyphrase in the introduction, keyphrase length, keyphrase density, keyphrase in the meta description, keyphrase in subheadings, a link with the focus keyphrase, keyphrase in image alt attributes, keyphrase in the title, keyphrase in the slug, previously used keyphrase, keyphrase distribution, text length, outbound links, internal links, SEO title width, meta description length, text length for taxonomy pages, and stale cornerstone content.

Yoast describes the density check as testing whether keyphrase words are used “often enough (but not too often)” and the text-length check as whether “the text is long enough.” That’s string matching, counting and length bands. Nothing in the set inspects whether the page is true, useful, or better than the page currently outranking you.

The readability analysis works the same way, and the vendor is candid about where its thresholds came from. A Yoast post explaining its methodological choices, dated June 2016 and now ten years old, carries a section headed “Little research on what is ‘right’ in writing!” and concedes the team “had to decide on some things to make readability checks.” It lowered the transition-word requirement because at the original threshold “most articles couldn’t meet our demands.”

The published thresholds are specific: passive voice recommended at a maximum of 10% of sentences, transition words green at 30% or higher and red below 20%, and sentences over 20 words flagged as too long. Those are defensible editing defaults. They’re not a model of what ranks.

What is the SEO title in WordPress? It’s the text that fills the <title> element and the clickable blue line in search results, and it’s separate from the post title WordPress prints on the page. WordPress core ships no field for it. Yoast adds one, and its readme describes “automated meta tag optimization right out of the box,” which is why every post on a Yoast site has a title even when nobody wrote one.

Yoast surfaces the field in the SERP preview it renders under the editor, listed as a free feature for both desktop and mobile results. Whatever the plugin generates for you is a default, not a decision. A WordPress SEO strategy decides which pages deserve a hand-written title and which are fine on the generated pattern, and that call comes out of keyword research rather than a width bar turning orange.

Is WordPress good for SEO? Yes, and the honest version of that answer is that the platform is almost never the constraint. Core ships clean permalinks, XML sitemaps since 5.5, responsive images, native lazy loading and, since 6.8, speculative loading. What it also ships is a template hierarchy that manufactures archive URLs nobody asked for, which is a different problem from being hostile to search engines.

Is WordPress SEO friendly out of the box? Friendlier than its reputation and less finished than the marketing suggests. Out of the box you get crawlable, indexable HTML with sane URLs, and you also get date archives, author archives and tag archives switched on by default.

Is WordPress or Shopify better for SEO? Neither, and that question usually stands in for a different one. We build on both, and in our experience the platform decision turns on what you sell and how you operate rather than on a ranking advantage that doesn’t exist. Shopify hands you hosting, checkout and a URL structure you don’t control; WordPress hands you control of every layer, which only helps if somebody owns those layers.

If the real question is whether to split a brand across several installs, that’s its own decision, and we’ve laid it out in multisite versus microsite.

This is where a WordPress SEO strategy either has a floor under it or doesn’t, and it’s the layer with no settings screen inside WordPress.

WordPress.org’s requirements page recommends PHP 8.3 or greater (opens in new tab), MariaDB 10.11+ or MySQL 8.0+, and HTTPS on every install. The same page concedes WordPress will still run on PHP 7.4+ and MySQL 5.5.5+, versions that “have reached official End Of Life and may expose your site to security vulnerabilities.” WordPress 7.1, released August 19, 2026, still carries PHP 7.4 as its minimum, two full branches below what WordPress.org recommends.

php.net’s supported-versions table doesn’t list 7.4 at all. The oldest branch on it is 8.2, which loses security support on December 31, 2026. If your host has you on 8.2, that’s roughly a four-month runway, and no SEO plugin has an opinion about it.

Google’s TTFB article, last updated November 2025, says most sites should aim for 0.8 seconds or less, with anything over 1.8 seconds classed as poor. Google also says plainly that TTFB isn’t a Core Web Vital, so treat it as a diagnostic rather than a target. It’s still the number no plugin can move, and it gates Largest Contentful Paint because it happens first.

Slow servers cost you crawling too. Google’s crawl budget documentation describes crawl health directly: when response times stay stable or improve the crawl limit goes up, and when the site slows down or returns 5xx or 429 responses the limit goes down and Google crawls less. Google’s March 2026 post on how Googlebot fetches pages repeats it, warning that crawlers back off automatically when a server struggles to serve bytes.

That same March 2026 post publishes a number worth designing themes around. Googlebot fetches up to 2MB for any individual URL, PDFs excepted, and stops the fetch exactly at the cutoff, with a 64MB limit for PDFs. Google’s words for everything past that line: those bytes “aren’t fetched, they aren’t rendered, and they aren’t indexed.” A theme that ships megabytes of inline CSS and menu markup ahead of the content can push your text and your structured data past a documented ceiling.

Google’s fix in that post is ordering: “Place your most critical elements, like meta tags, <title> elements, <link> elements, canonicals, and essential structured data, higher up in the HTML document.” That’s a theme and build decision, and it’s the kind of thing a technical SEO audit exists to catch.

Below the theme, WordPress accumulates weight in three places: post revisions, expired transients and autoloaded options. Since 6.6, core stops autoloading any single option larger than 150,000 bytes, and Site Health flags a performance issue once combined autoloaded options pass 800 KB, which gives you a dashboard signal instead of a hunch. WordPress’s revisions documentation also kills a popular myth on the way past, noting there’s only ever one autosave per user per post, so “your tables do not grow by one row every 60 seconds.”

The transients documentation is blunter, saying WordPress “infrequently cleans out expired transients,” which is why cleanup tooling exists at all. Persistent object caching is a hosting decision as well: WordPress’s own class reference says cached data lives in memory only for the duration of the request “unless you install a persistent caching plugin.” Keeping that layer healthy across a portfolio is its own discipline, and we’ve written up the maintenance stack we run for it.

Core Web Vitals belong in a WordPress SEO strategy because Google says its ranking systems use them, and they belong to your build rather than to your plugin. Google’s page experience documentation, last updated December 2025, answers the framing question directly: there is no single page experience signal (opens in new tab), and beyond Core Web Vitals, other page experience aspects “don’t directly help your website rank higher in search results.”

The same page hedges the part that gets quoted hardest. Good results in Search Console’s Core Web Vitals report or in third-party tools “doesn’t guarantee that your pages will rank at the top of Google Search results,” and Google adds that “trying to get a perfect score just for SEO reasons may not be the best use of your time.” Google’s magnitude language, in a 2021 post that now carries Google’s own outdated-content banner, is “one of many factors,” with a note that sites shouldn’t expect drastic changes.

There are three metrics. Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, each assessed at the 75th percentile of page loads and segmented across mobile and desktop. INP replaced First Input Delay on March 12, 2024, and Chrome tools ended FID support entirely on September 10, 2024. Google’s own lifecycle roster lists those three as stable with nothing pending.

A performance strategy for a WordPress site starts with what core already ships, and every version number is public. Responsive srcset and sizes landed in 4.4. Big-image downscaling at 2560 pixels landed in 5.3. Native lazy loading arrived in 5.5, and 5.9 refined it so the first content image is skipped.

WordPress 6.3 added fetchpriority="high" on the image core identifies as the LCP element, which the dev note says typically improves LCP by 5 to 10%. WebP uploads landed in 5.8, AVIF in 6.5, sizes="auto" in 6.7, speculative loading in 6.8, and 7.1 moved compression, resizing and thumbnail generation into the browser using WebAssembly. WordPress 6.9’s on-demand block style loading cut average CSS by 45% on sample classic-theme pages, and the release notes published the tradeoff in both directions: TTFB rose 7% on classic themes and 4% on block themes because of the output buffering, while LCP improved about 4% on classic themes and 25% on block themes.

One thing core still won’t do is generate WebP or AVIF versions of what you upload. Converting uploads by default was proposed for 6.1 and publicly reverted (opens in new tab) after Matt Mullenweg opposed it, with the work pushed into the Performance Lab feature plugin. Four years later it’s still the Modern Image Formats plugin at version 2.7.1 and 100,000-plus installs, and existing images have to be regenerated by hand.

Check the rest of Performance Lab before you put it on a client site. Image Prioritizer, Embed Optimizer and Optimization Detective are all still on 1.0.0 beta releases, Optimization Detective does no optimizing on its own and needs real visitor metrics before anything acts on them, and the Web Worker Offloading plugin’s own page says the functionality is intended to be sunset.

Google’s measurement guidance names the data that decides the assessment: real user monitoring, also called field data, “is what Google uses to determine whether a site meets the recommended Core Web Vitals thresholds.” Google classifies Lighthouse and WebPageTest as lab tools on that same page.

Lighthouse structurally can’t measure one of the three. Google’s lab-tools table marks Lighthouse as covering LCP and CLS but not INP, because a simulated load has no user input to respond to, with Total Blocking Time offered as the lab proxy. A perfect Lighthouse performance score tells you nothing directly about a third of your Core Web Vitals.

Field data comes from the Chrome User Experience Report on a 28-day rolling window, updated daily, and its eligibility rules have a WordPress-specific consequence. A page has to be publicly discoverable by the same indexability criteria search engines use, so a noindex you set in an SEO plugin also drops that page out of CrUX. The dataset only includes Chrome users who enable usage statistics and sync history without a passphrase, and it excludes Chrome on iOS, Android WebView and other Chromium browsers entirely.

For scale, the July 2026 CrUX release covers 18,059,068 origins, of which 55.7% pass all three Core Web Vitals, up from 53.5% a year earlier. Passing puts you in the better half of the web rather than in rare company, which is the right context for deciding how hard to chase it. On a commerce build the same latency shows up in revenue, which we’ve written about in checkout speed and revenue.

If you still reach for WebPageTest, its situation changed twice. Catchpoint acquired it in September 2020, and LogicMonitor’s acquisition of Catchpoint was announced on December 2, 2025, though webpagetest.org still names Catchpoint and says nothing about what changes. The code sits under the Polyform Shield license rather than an OSI open-source one.

Pricing is as of August 2026 and vendor pricing moves. Catchpoint’s free Starter tier is 150 test runs a month with 3 runs per test, 30 locations and 60-day retention, and the vendor defines a run as a single page load, so five tests with repeat views spends ten runs. Professional starts at $180 a year. Fixing what those tools find is the Core Web Vitals work itself, not the measuring.

Google’s structured data gallery is the list that governs this, and its table carries 25 feature types (opens in new tab) as of the June 2026 update: Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental and Video. The table isn’t the whole set, since Book actions, Fact check and the shopping sub-guides live in the same navigation.

FAQ rich results are gone. Google’s documentation changelog carries the notice: the feature stopped appearing in Google Search on May 7, 2026 (opens in new tab), and the documentation page itself was removed on June 15, 2026. An August 2023 announcement had already restricted FAQ rich results to well-known, authoritative government and health sites before that.

HowTo has been dead longer. The same 2023 post limited HowTo to desktop, then a September 14, 2023 update stated that Google stopped showing HowTo rich results on desktop as of September 13, 2023, which deprecated the type outright.

The sitelinks search box came off the results page starting November 21, 2024. Yoast, Rank Math and AIOSEO all still emit WebSite schema carrying a SearchAction by default, and that half of the markup now does nothing.

Don’t rip out WebSite schema on the strength of that. Google’s own announcement notes that site names use a variation of WebSite structured data that continues to be supported. The dead part is the potentialAction, not the object it hangs on.

Six more types were phased out after a June 2025 announcement. Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement and Vehicle Listing lost Search Console and Rich Results Test support on September 9, 2025. Book Actions was announced in that same group and then reinstated on November 5, 2025, because a feature in Search still uses the markup, so it stays in your graph. Practice problems were phased out with documentation removed on January 6, 2026, and Dataset was clarified as feeding Dataset Search rather than Google Search.

Breadcrumbs are the subtler case. Google stopped showing breadcrumbs on mobile search results in January 2025 while continuing to support the markup for desktop results. Since mobile-first indexing completed on October 31, 2023 and desktop crawling for Search ended on July 5, 2024, breadcrumb markup is still correct and mostly invisible.

Meanwhile, Yoast’s plugin listing still advertises “HowTo and FAQ blocks with built-in schema support” as a free feature, and AIOSEO’s schema page still lists FAQ and HowTo among its 20-plus supported types. Both are vendor descriptions of their own products, and neither is inaccurate about what the plugin outputs. The output just doesn’t produce a rich result anymore.

Dead markup isn’t a penalty, and Google says so in its structured data policies: a structured data manual action costs a page its rich result eligibility and “doesn’t affect how the page ranks in Google web search.” What it costs you is the assumption that the plugin’s defaults are current.

The useful version is narrow. Mark up what the page actually is, fill the required properties completely, and confirm it in the Rich Results Test rather than trusting the SEO plugin’s checkbox. Google’s guidance prefers “fewer but complete and accurate recommended properties” over every possible property filled in badly, and the old Structured Data Testing Tool is gone, redirecting to Google’s tool chooser with generic validation now at validator.schema.org.

Know what the plugins will and won’t build for you. Yoast ships no schema builder at any price and says so as policy, having decided against one because anyone able to implement schema themselves “probably doesn’t need our help anyway.” Rank Math sells a custom schema builder in PRO and claims 840-plus supported types, AIOSEO ships one that accepts any JSON-LD, and Slim SEO sells one in Pro with 30-plus prebuilt types. Those four are all vendor descriptions of their own products.

WordPress generates archives from its template hierarchy whether or not anyone planned them: category, tag, author, date, and one archive per term in every publicly rendered taxonomy. WordPress’s own theme handbook puts the author case bluntly: “An archive URL is generated for all users on a WordPress site, regardless of whether they have published posts.” Pagination is manufactured by a default too, since WordPress shows 10 posts per page unless you change it, which is what produces /page/2/ and /page/3/ on every archive you have.

Do WordPress tags help SEO? Sometimes, and for most sites the strategy is subtraction. A tag archive earns its place when the tag is a real topic people search for and the archive holds enough posts to work as a landing page. Twenty tags applied once each produce twenty thin pages that duplicate content from the posts you’d rather rank.

Google’s guidance on empty category pages transfers directly to this: “If a category has no items, use a noindex robots meta tag,” and if the site automatically removes an emptied category, “consider returning a 404 (not found) HTTP status code for the page.” Google’s definition of a soft 404 covers the near-empty case as well, describing content that suggests an error or an empty page. An archive with one post isn’t far from an archive with none.

Attachment pages are the same problem with a date attached. WordPress 6.4 disabled them for new installations, and the dev note by Joost de Valk is explicit about why: “these attachment pages don’t add any meaningful information” and yet they “exist, get indexed by search engines, and sometimes even rank in search results.” That fix only reaches new installs. Any site that existed before 6.4 and upgraded kept wp_attachment_pages_enabled set to 1 and still generates them, which covers most sites we inherit.

Two controls do different jobs, and using both on one URL cancels them out. Google’s robots.txt introduction says the file manages crawler access and is not a mechanism for keeping a web page out of Google (opens in new tab). A blocked URL can still appear in results, without a description, if other pages link to it.

noindex is the control that keeps a page out, and it only works if Googlebot can reach the page. Google’s block-indexing documentation spells out the collision: “If the page is blocked by a robots.txt file or the crawler can’t access the page, the crawler will never see the noindex rule, and the page can still appear in search results.” Specifying noindex inside robots.txt isn’t supported at all.

Noindex doesn’t save crawl either. Google’s crawl guidance says it will still request the page and then drop it when it sees the rule, which spends crawl time rather than saving it. Pick the control that matches the outcome you want and use one of them.

Google grades canonicalization methods by strength, and the word it uses throughout is signal. Redirects and rel="canonical" are described as strong signals, sitemap inclusion as a weak one, and Google says none of them are required because it will otherwise pick the version it considers best. Search Console has a status for when it disagrees with you, “Duplicate, Google chose different canonical than user,” which is the citable proof that your tag is an input rather than an instruction.

Two habits carried by older WordPress plugin advice now run against Google’s current pagination documentation. Don’t canonicalize /page/2/ back to page one; Google says to give each page in the sequence its own canonical URL. And don’t work to make paginated titles unique, because Google says pages in a sequence can share titles and descriptions. Google confirmed in 2019 that it no longer uses rel=next and rel=prev, and its current pagination guidance (opens in new tab) is what to follow instead.

Crawl budget gets more anxiety than Google asks for. The guide opens by telling most people to stop reading, and the thresholds it names are 1 million or more unique pages changing weekly, or 10,000 or more changing daily (opens in new tab), which Google calls rough estimates rather than exact numbers. If your pages get crawled the same day you publish them, this isn’t your problem.

What does apply to a normal site is what Google calls perceived inventory: duplicate URLs spend crawling time, and Google calls it “the factor that you can positively control the most.” Faceted navigation is the biggest reported source of overcrawl, and WordPress archives are the smaller domestic version of the same pattern.

Going headless is the point where a WordPress SEO strategy stops being a configuration and becomes an engineering commitment. In a coupled install, Yoast emits the <head>. In a decoupled build, Yoast produces data, and something you write has to render it.

This site is built the way this section describes. It’s a Next.js front end on React 19, pulling WordPress through WPGraphQL, with Yoast installed on the WordPress side.

Four responsibilities that a coupled install would hand to plugins live in the front end here. The sitemap is generated by the application, which queries post, project and page slugs from WordPress and emits URLs on the requesting host. robots.txt is generated the same way, with per-agent rules and an explicit AI-bot allowlist. Redirects are executed by front-end middleware, renamed Proxy in Next.js 16, which polls a redirects field the WordPress theme exposes and refreshes at most once a minute.

The fourth is structured data, and it’s the one that settles the argument about defaults. Rather than passing Yoast’s schema string through, this site hand-builds its JSON-LD in roughly 510 lines of front-end code, with separate builders for Organization, Article, Breadcrumbs, WebSite and ProfessionalService. A hand-built graph doesn’t emit a dead SearchAction.

Yoast’s fields are still queried, they’re just remapped, and a comment in this codebase records why. Yoast builds absolute URLs from the WordPress install’s home URL, so every canonical, og:url and breadcrumb it hands over points at the wrong host, and the path has to be re-anchored onto the public origin.

The robots.txt case is the airtight one. Google’s documentation says the file “must be located at the root of the site host to which it applies,” that it “cannot be placed in a subdirectory,” and that it “applies only to paths within the protocol, host, and port where it is posted.” WordPress serves robots.txt from the WordPress host, which in a headless build isn’t the host anyone searches for, so the plugin’s robots settings govern a domain your customers never see.

Redirects have the same shape. Yoast’s help documentation describes PHP-based redirects as the default, .htaccess as the faster Apache option, and nginx as unsupported, and all three execute on the WordPress server. In headless the public request never reaches that server, so the redirect table becomes data to query rather than an engine that fires. The WPGraphQL Yoast add-on exposes it as redirects { origin target format type }, which turns Yoast from the redirect engine into the redirect source of truth.

Crawl budget splits as well. Google’s crawling infrastructure defines a site as a unique hostname, so the WordPress host and the public host are separate sites with separate budgets by Google’s own definition.

The objection that decoupled builds can’t do server-rendered meta tags is answered in Next.js documentation: resolving generateMetadata is part of rendering, so when a page can be prerendered the metadata lands in the initial HTML. One real difference to plan for is that Next.js redirects use 308 and 307 rather than 301 and 302, to preserve the request method. If you’re moving an existing site into that shape, the sequencing matters more than the stack, and we’ve documented ours in migrating without losing SEO.

Go headless when three things are true at once. You need front-end performance or interaction models a PHP theme won’t reach, you have engineers who will own the sitemap, robots, redirects and schema permanently, and your editors can live with a preview and publish flow somebody has to build. When any of the three is missing, stay coupled, because everything Yoast does for free becomes something you maintain.

Two dependency facts shape that decision. WPGraphQL became a canonical plugin on WordPress.org in October 2024, which its lead developer describes as a canonical community plugin rather than core, and its WordPress.org listing shows 30,000-plus active installs. The bridge exposing Yoast to GraphQL is a separate community add-on maintained by a single developer at 10,000-plus installs, actively updated as of August 11, 2026, and still a single-maintainer dependency.

Yoast’s own documented headless path is REST, not GraphQL. Its developer documentation describes yoast_head and yoast_head_json fields plus a get_head endpoint, and no page in that documentation mentions GraphQL. Yoast’s documentation also concedes a technical limitation: the JSON output still contains schema data even when the filter that disables schema output is applied, “because the HTML and JSON outputs use different code paths.” That’s the vendor confirming two output paths, and headless consumes the one the plugin never renders.

One measurement change announced in 2026 lands directly on decoupled front ends. Client-side route changes in single-page applications have never been fully covered by Core Web Vitals, and Chrome’s July 2026 update says the soft navigations feature is launching unflagged for all sites from Chrome 151. Until that lands, in-app navigations are invisible to the metrics Google assesses.

Start with the differences the vendors document themselves. Yoast’s redirect manager is Premium only, at $118.80 a year excluding VAT for one site as of August 2026, and vendor pricing changes. Rank Math ships a redirect manager in its free tier, and so does Slim SEO. AIOSEO puts its redirection manager behind paid tiers, and SEOPress gates the full manager behind PRO while allowing post-level redirects free.

Renewal terms differ more than the headline prices do. AIOSEO’s pricing page states that all pricing is introductory and “all renewals are at full price,” so a $49.50 Basic renews at $99 and a $299.50 Elite renews at $599. Rank Math’s page, rendered in euros, shows PRO at €7.99 a month promotional and €8.99 at renewal plus taxes, billed annually. SEOPress says the opposite on its own page, “renew at the same price every year,” at $49 a year for one site.

Slim SEO ships no content analysis and no traffic lights at all. Its readme argues that SEO “should be an integrated part of WordPress” and that the plugin “doesn’t have any settings page.” At 70,000-plus installs that’s a small constituency, and it’s a vendor’s framing, but it’s the existence proof that the score was never the target.

Be fair about the ratings before you use them. Yoast holds 4.8 across 27,818 ratings, Rank Math 4.8 across 7,493, AIOSEO 4.7 across 5,197, SEOPress 4.8 across 1,245, and Slim SEO 4.7 across 135. A 4.8 held across 27,818 reviews is a harder number to hold than a 4.8 across 1,245, and none of those numbers describe how a plugin behaves on your stack.

So, rank math vs yoast: if you want a redirect manager without paying, Rank Math’s free tier has one and Yoast’s doesn’t. If you want unlimited free keyphrases, that’s SEOPress or AIOSEO rather than either of these two, since Rank Math’s free tier caps focus keywords at five unless you add a filter. A schema builder is paid everywhere it exists, and Yoast doesn’t sell one at all.

If you want the plugin tested against current core, Yoast’s WordPress.org listing is the only one of the five reporting tested-up-to 7.1 while the other four report 7.0.4. Neither choice changes anything in the three sections above.

Yoast free now ships LLMs.txt management and SEOPress ships an agent-readiness toggle, both vendor descriptions of their own products. Google’s generative AI guidance, last updated July 2026, says you don’t need to create AI text files or special markup to appear in Google Search “as Google Search itself doesn’t use them,” and that keeping them will neither harm nor help visibility there. Other systems read those files. Google Search ignores them, which makes that a reason to buy a plugin only if those other systems matter to you.

A WordPress SEO audit that only reads the plugin’s own report will tell you the site is fine, so the strategy is to work inward from what you can’t control toward what you can.

Start with what Google already tells you. The Page Indexing report’s statuses are the cheapest diagnosis available, and the current labels are specific: “Crawled – currently not indexed,” “Discovered – currently not indexed,” “Duplicate without user-selected canonical,” “Duplicate, Google chose different canonical than user,” “Indexed, though blocked by robots.txt,” “Soft 404,” and “URL marked ‘noindex’.” The older “Excluded by ‘noindex’ tag” label is retired.

Each status points at a different layer of the stack. Duplicate statuses point at archives and canonicals. Discovered but not indexed points at crawl capacity, which points back at server response times. Indexed though blocked by robots.txt is the trap from the section above, seen from Google’s side of it.

Check field data before lab data, because field data is what the assessment uses. When a page has too few samples, PageSpeed Insights falls back to origin-level data covering every page on the site, which is why a quiet page’s numbers often describe your home page instead. PageSpeed Insights also updates daily on a trailing 28-day window, so a fix you shipped this morning won’t show up this afternoon.

Then read the pages themselves, which is where on-page work starts. If rankings fell rather than never arrived, that’s a different sequence entirely, and we’ve written it up in a piece on diagnosing a drop in rankings.

Here’s the checklist, ordered by how much of the strategy each item unlocks rather than by how fast it is to do. Every figure behind it appears in the sections above, with its source.

None of it substitutes for having something worth ranking. Google’s helpful content guidance says there’s no preferred word count and asks you to evaluate a page on who made it, how it was made, and why it exists. That’s the work a content strategy does and no plugin can.

If the checklist is clean and the page still isn’t moving, the strategy shifts from technical WordPress SEO work toward competitive work. Yoast’s own list named the remaining levers: links from other sites, internal linking structure, intent match, uniqueness and competition.

Intent is the cheapest of those to check and the most commonly wrong. If the query returns comparison pages and yours is a service page, the format is the problem and no amount of optimization fixes it.

Internal linking is the lever WordPress makes easiest and most sites still underuse. Every post you publish is a chance to link the page you actually want ranked, with anchor text that describes the destination rather than saying “learn more.”

Local intent changes the shape of everything above. When customers search with a place attached, the work moves toward local SEO and the profile surfaces that sit outside your site entirely.

Give it time, and say so out loud to whoever’s asking. Google’s starter guide states that changes take time to reflect, with some visible in a few hours and others taking several months, which is the honest answer when someone wants a date.

You built something worth finding. When the plugin says you’re optimized and the traffic says otherwise, the gap sits in a layer the plugin can’t see: the server, WordPress core itself, the theme, the archives WordPress made on its own, or the front end.

Schedule a free Growth Audit and we’ll show you which layer is costing you. Not a sales call. Not a quote request. A clear look at why you’re not getting found, with a roadmap for fixing it.

If you’d rather start on the ranking side, our Denver SEO team does this work across WordPress and Shopify builds.