Beyond Your WordPress Plugin: 5 Tools for Technical SEO

Your WordPress SEO settings can look right while the public page still has a problem. A theme update changes the markup. A permalink change leaves old links behind. A new script makes the mobile experience slower.

An SEO plugin is useful for controlling what your site should output. For WordPress technical SEO, I'd also keep a few tools that check what actually reaches the outside world.

These five cover different questions: what a crawler finds, what Google has indexed, how a page performs, whether its structured data is eligible for supported rich results, and what needs another technical review.

This comparison is based on current product documentation, not a benchmark on a test WordPress installation. The aim is a small, useful inspection workflow after a change—not another pile of plugins to maintain.

Which technical SEO tool answers which question?

Tool	Use it for	Cost reference	What a good result doesn't prove
Screaming Frog SEO Spider	Site-wide links, responses, redirects and metadata	Free up to 500 URLs; paid £199/year	Google has indexed those URLs
Google Search Console	Google's indexed record and live URL checks	Free	A successful live test guarantees indexing
PageSpeed Insights	Performance diagnosis on mobile and desktop	Free web tool	One lab run represents every visitor
Rich Results Test	Google-supported structured data checks	Free web tool	Google will display a rich result
Screpy	External technical SEO review across a project	Pro regular annual price: $192	The report has changed your WordPress site

Prices checked November 3, 2026. Annual prices mean annual billing, and the currencies aren't converted here. Confirm taxes, licence scope, and any offer conditions on the vendor's current page.

1. Screaming Frog: investigate changes across the site

Screaming Frog SEO Spider is a desktop crawler for Windows, macOS, and Linux. It helps you examine response codes, redirects, titles, and canonical tags across URLs instead of checking every WordPress editor screen.

I'd reach for it after changing permalinks or navigation. The question is concrete: do internal links reach the intended destination, or are they pointing to broken pages and unnecessary redirects?

Look for shared patterns before assigning individual fixes. If every link in one menu points through an old path, updating that menu may be more useful than editing unrelated posts.

The free version crawls up to 500 URLs. Archives, pagination, and other reachable URLs count too; 400 posts doesn't necessarily mean a complete crawl fits. The paid licence is listed at £199 per year.

Choose it for: a focused crawl investigation. A clean crawl only describes the URLs and conditions inspected. It isn't Google's indexing decision or proof that an undiscovered page has no issues.

2. Google Search Console: separate the live page from Google's record

Google Search Console answers a different question from a crawler: what does Google report about this URL? You'll need access to the relevant site property.

The URL Inspection documentation distinguishes the indexed version from a live test. That matters when you've just removed an unintended indexing restriction or corrected a canonical setting.

Use the live test to investigate whether the current page might be indexable. Use the indexed information to examine Google's existing record, including the Google-selected canonical when available. The live test cannot predict that canonical selection.

Don't mark a release as fully processed by Google just because the live test succeeds. Record which version you inspected and what remains to be checked later.

Choose it for: Google-specific indexing evidence. It's free, but it doesn't edit your WordPress settings, and an indexing request is not a guarantee of inclusion.

3. PageSpeed Insights: diagnose the page visitors receive

PageSpeed Insights is useful after adding a page builder block, changing a theme, or introducing a third-party script. Test the affected page rather than assuming the homepage represents the whole site.

Google's documentation separates controlled lab diagnostics from real-user field data. Lab results help you investigate the current page. Available field data describes a historical collection window of the previous 28 days.

Those aren't interchangeable release checks. A lab run can help you investigate a new problem now; the field view won't instantly become a clean measurement of your latest deployment. Check whether the displayed field data applies to the URL or the broader origin. Some pages don't have enough real-user data for a field assessment.

For a useful comparison, keep the tested URL and device category consistent and record what changed. A single score moving up or down isn't enough to identify the cause.

Choose it for: free, page-level performance diagnosis. It provides evidence to investigate; it doesn't configure your cache or optimize your theme for you.

4. Rich Results Test: inspect the structured data your site publishes

Google's Rich Results Test is useful after changing a theme or a plugin setting that affects structured data. Test the public URL so you're checking the generated output, rather than only the values entered in WordPress.

For example, after changing an article template, inspect which supported items the tool detects and whether it reports errors. Then compare the detected information with the visible page. Passing a technical check doesn't make an incorrect author or misleading detail accurate.

Google describes this tool as a check for Google-supported rich results, not a universal validator for every Schema.org type. It also explicitly says correct markup doesn't guarantee rich-result display.

Choose it for: a free check of supported structured data after an output change. It won't repair conflicting theme and plugin output, or tell you that your entire site's technical SEO is finished.

5. Screpy: keep external technical review in your maintenance routine

I'm a co-founder of Screpy, so that's my connection to this recommendation.

Its SEO crawler helps you review technical findings and affected URLs across a public website, including metadata, links, and indexability. For WordPress maintenance, the useful habit is returning to those findings after changes, rather than treating the launch audit as permanent evidence.

Give each fix a simple record: affected URL, expected output, change made, and follow-up result. If a problem appears across several pages, investigate the shared source before editing them individually.

Pro's regular annual price is $192, with five projects and 5,000 crawl pages per project. That is annual upfront billing. Conditional welcome offers are separate; subscriptions renew automatically and a trial becomes paid unless cancelled before it ends.

Choose it for: keeping project-wide technical review part of ongoing maintenance. It complements your WordPress tools; it isn't a native WordPress editor and doesn't automatically apply theme or plugin fixes.

Match the tool to the WordPress change

Here's an illustrative release checklist. It isn't a claim that every update needs every check.

Change or symptom	Start here	Evidence to record	Still unknown
Permalinks or navigation changed	Screaming Frog	Old link, response, final destination	Whether Google has reprocessed the change
Important page missing from Google	Search Console	Indexed record and separate live result	Whether or when Google will index it
New script or heavier page layout	PageSpeed Insights	URL, device, lab diagnostics, field-data scope	Impact on every real visitor
Theme or structured-data output changed	Rich Results Test	Detected supported items and errors	Whether a rich result will appear
Technical findings need follow-up	Screpy	Affected URLs, changes and repeat-review findings	Problems outside the inspected scope

For a small WordPress site, I'd begin with the free checks that answer the current problem. Add paid crawl capacity or a project workflow when its limits or the repeated work justify the cost. You don't have to buy both crawler options to start.

Keep the SEO plugin that already handles your publishing settings well. Use these tools to verify the result, then fix the actual source of the problem. That gives each tool a clear job—and gives you a better stopping point than “the score turned green.”