Most WordPress SEO advice is about content: keywords, headings, meta descriptions, internal anchor text. That work matters, but it assumes something upstream is already true, that Google can crawl your site, render your pages, and understand what it's looking at. Technical SEO is the layer that makes that assumption safe to make. Skip it and your best content can sit unindexed, or indexed but ranked below a technically cleaner competitor with thinner copy.
What counts as technical SEO, and what doesn't
Content SEO is about relevance: does this page answer the query, is it structured well for the topic, does it use the right terms. Technical SEO is about access and trust: can a crawler reach the page, can it render the page the way a user would see it, does the page load fast enough, is the URL the canonical version, and does the markup tell search engines what type of content this is. You can write a perfect article and still lose if the page is blocked in robots.txt, missing from your sitemap, or duplicated across three URLs with no canonical tag pointing to the original.
The distinction matters because the two disciplines fail differently. Weak content SEO shows up as pages that rank but underperform. Weak technical SEO shows up as pages that never get evaluated at all, because they were never crawled, or were crawled and dropped for being duplicates, or loaded so slowly that Googlebot's rendering budget ran out before the content appeared.
WordPress makes both easier and harder than a hand-built site. Easier, because the platform and its plugin ecosystem automate a lot of the technical baseline, sitemap generation, canonical tags, robots meta output. Harder, because plugin stacking, theme bloat, and default settings that were fine for a five-page brochure site quietly break down as a site grows. Most of what follows is about closing that gap.
Crawlability and indexability fundamentals
Before Google can rank a page, it has to find it (crawlability) and decide it's worth keeping in the index (indexability). These are separate gates, and WordPress sites commonly fail one without realizing the other is also at risk.
robots.txt
Your robots.txt file tells crawlers which paths they're allowed to request. WordPress generates a virtual one by default, but it's common for that default to get overwritten by a security plugin, a staging-to-production migration that forgot to update it, or a well-meaning `Disallow: /` left over from development. Check yours at `yoursite.com/robots.txt` and confirm it isn't blocking `/wp-content/uploads/`, your CSS and JS directories, or any content section you actually want indexed. Blocking a directory doesn't deindex pages already in Google's index, it just stops Google from re-crawling them, which means stale content stays stale and new content in that path never gets discovered. For a full walkthrough of syntax, directives, and WordPress-specific gotchas, see the robots.txt guide for WordPress.
XML sitemaps
A sitemap is a direct list of the URLs you want indexed, submitted to Google Search Console so discovery doesn't rely purely on link-following. WordPress core has generated a basic sitemap since 5.5, but most sites use an SEO plugin's version instead because it handles exclusions, image sitemaps, and splitting large sites into indexed sub-sitemaps more reliably. The failure mode to watch for is a sitemap that includes noindexed pages, redirects, or 404s, which wastes crawl attention and signals a lack of housekeeping. Rankwyn's sitemap and indexing tooling keeps the sitemap synced with what's actually indexable, so you're not manually auditing it after every content push. If you're setting one up from scratch, the XML sitemap guide covers the setup end to end.
Canonical tags
WordPress is prone to serving the same content at multiple URLs: a post reachable through its permalink, a category archive, a tag archive, and sometimes a paginated or parameterized variant. Without a canonical tag pointing each duplicate back to the preferred URL, Google has to guess which version to index, and it doesn't always guess the one you'd choose. Most SEO plugins set self-referencing canonicals automatically, but check that pagination, filtered product listings (on WooCommerce sites), and print or AMP variants aren't creating unintended duplicate signals.
Indexed doesn't mean ranked, but unindexed guarantees zero traffic
It's tempting to treat crawlability as a solved problem once a site is live. Check Search Console's Page Indexing report periodically. Pages silently drop out of the index for reasons that have nothing to do with content quality, a broken canonical, a noindex tag left on after a staging push, or a sitemap that stopped updating.
Core Web Vitals for WordPress
Core Web Vitals measure real-world page experience: how fast the main content loads, how quickly the page responds to interaction, and how much the layout jumps around while loading. Google uses these as a ranking signal, and it measures them at the 75th percentile of real visits, across both mobile and desktop, not a single lab test run. The three metrics and their current "good" thresholds, per Google's own web.dev documentation, are below.
| Metric | What it measures | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Time until the largest visible element renders | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to user interaction across the full page visit | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much visible content shifts unexpectedly during load | 0.1 or less |
Core Web Vitals "good" thresholds
Source: web.dev, Core Web Vitals thresholds
On WordPress specifically, poor Core Web Vitals scores tend to trace back to a small set of repeat offenders. Heavy themes, particularly page-builder-driven themes that load large CSS and JavaScript frameworks on every page regardless of whether the page uses their features, inflate both LCP and INP. Unoptimized images are the single most common LCP killer: a hero image uploaded straight from a camera or stock library at full resolution, with no compression, sizing, or modern format (WebP/AVIF) conversion, can single-handedly push LCP past the 2.5 second threshold. Render-blocking plugins, anything that injects synchronous JavaScript or CSS into the `<head>`, chat widgets, popup builders, some analytics snippets, delay the point at which the browser can paint anything. And simply running too many active plugins compounds all of the above, because each one adds its own database queries, asset requests, and hook executions on every page load, whether or not that plugin's feature is used on that particular page.
- Audit installed plugins and deactivate anything not actively used, each active plugin adds real request overhead even when idle.
- Serve images in modern formats, sized correctly for their display dimensions, with lazy loading on everything below the fold.
- Defer or async non-critical JavaScript, and move third-party scripts (chat, popups, marketing pixels) to load after first paint.
- Use a caching layer and a CDN so repeat visits and geographically distant visitors aren't hitting your origin server for every asset.
- Reserve space for images, embeds, and ads with explicit width and height attributes to prevent layout shift as they load.
Fixing Core Web Vitals is rarely a one-time task, plugin updates, theme changes, and new content all shift the numbers. Rankwyn's site maintenance tooling monitors these metrics on an ongoing basis rather than leaving it to a quarterly manual audit, which is how most WordPress sites end up finding out about a regression months after it happened.
Structured data as a technical layer
Structured data, usually implemented as JSON-LD, doesn't change how your page looks to a human visitor, but it changes how precisely a search engine can parse what the page is. Marking up a recipe as a Recipe, a product as a Product with price and availability, or an article with its author and publish date gives Google structured facts instead of forcing it to infer them from unstructured HTML. That's the difference between a page that's eligible for rich results (star ratings, price ranges, FAQ dropdowns in the search listing) and one that isn't, and it's also a trust signal in its own right: consistent, valid structured data tells search engines the site is well-maintained.
The technical part is where WordPress sites go wrong. It's common to end up with duplicate or conflicting schema, one block from the theme, another from an SEO plugin, a third from a page builder, all outputting overlapping JSON-LD for the same page. Validate what's actually being emitted rather than trusting that a plugin's schema toggle worked as expected. Structured data built to stay consistent as you add page types avoids the layering problem, since a single source of truth for markup beats three plugins each assuming they own it.
Site architecture: internal linking, URL structure, and orphan pages
Architecture is the part of technical SEO that's easy to get right at launch and easy to let rot as a site grows. Three things matter most in practice. First, internal linking: every important page should be reachable within a few clicks from the homepage, and should receive links from other relevant pages on the site. Internal links are how both crawlers and topical relevance signals flow through a site, a page with no incoming internal links is effectively invisible to that flow even if it's technically indexed.
Second, URL structure. WordPress defaults to a reasonably clean permalink structure, but sites migrated from other platforms, or reconfigured mid-life, often end up with inconsistent patterns, some URLs with dates, some with category prefixes, some flat. Pick a structure and keep it stable, changing URL patterns after a site has accumulated backlinks and rankings means managing a redirect map, and every unmapped redirect is a small loss of authority.
Third, orphan pages, pages that exist and may even be indexed, but have no internal links pointing to them from anywhere else on the site. These accumulate naturally: an old landing page from a campaign, a category that used to have a menu entry, a post that got unlinked during a redesign. They're worth finding and either linking back into the site's structure or retiring properly, because an orphan page is dead weight in your crawl budget and a signal to Google that parts of your site aren't maintained.
Architecture compounds
Unlike a slow page, which you can usually fix in an afternoon, a tangled site architecture takes real planning to unwind. The sooner a growing WordPress site settles on a consistent URL and linking structure, the less expensive it is to maintain going forward.
None of this replaces content quality, but it sets the floor content quality operates above. A technically sound WordPress site lets a search engine spend its attention evaluating what you wrote instead of working around what's broken. If you're deciding where to invest first, Rankwyn's plans are built around exactly this order of operations: fix the technical foundation, then scale content on top of it.