Printable WordPress SEO checklist with 20 numbered checks in three groups: access and indexing, content, links and images, and usability and upkeep, each with boxes to mark pass, fail or not assessable

Start by confirming that Google can reach and index the pages you actually want found: your homepage, your main service pages and your contact route. Once that is settled, check that each page is easy to understand, works well on a phone and makes it simple for a customer to get in touch.

This checklist is written for owners of UK service businesses who can log in to WordPress but are not developers. Each check tells you where to look, what a passing result looks like, what a problem means and whether you can safely fix it yourself or should ask your developer, host or an SEO specialist.

A first pass over checks 1–8 on your most important pages can usually be done in one sitting. Diagnosing and repairing what you find usually takes longer, and some fixes belong with your host or developer.

Before you start: four terms that matter

These words describe different stages, and a page can pass one and fail the next.

Discovery: Google learns a URL exists, for example from a link or a sitemap.
Crawling: Google’s crawler fetches the page.
Indexing: Google stores the page and may show it in results.
Ranking: where an indexed page appears for a particular search.

Fixing a crawling or indexing problem removes a barrier. It does not guarantee a ranking.

How to use this checklist and record your findings

Jump to: Checks 1–8: access and indexing · Checks 9–14: content, links and images · Checks 15–20: usability and maintenance · Checklist summary · When to ask for help

For a sensible first session:

Pick your homepage, your two or three most important service pages and your contact page.
Run checks 1–8 on those pages, and record each result with a screenshot.
Fix the highest-impact confirmed problem first. An accidental noindex or a blocked page matters more than an image warning.
Leave anything you’re unsure about, and note it for help.
Work through checks 9–20 over the following weeks.

Keep a simple log as you go: the date, the URL checked, the check number, pass, fail or Not assessable, and a screenshot or note of what you saw. If you cannot see the evidence for a check, mark it Not assessable rather than guessing. That log is what a developer or SEO will need if you ask for help.

Self-hosted or WordPress.com? Most of this guide uses self-hosted WordPress (WordPress.org) labels. On WordPress.com the visibility controls work differently and are named differently; where that matters, it is noted.

Checks 1–8: access, indexing and preferred URLs

1. The site Google can reach is the one you intend

Your public site should be the live version, and any staging copy or private area should be protected.

Why it matters: a staging copy that is publicly reachable can compete with your real site, while a live site still carrying staging settings can be hidden.
Where to check: ask your developer or host whether a staging or development copy exists and what address it uses. Visit it while logged out. Search Google for site: followed by your domain and look for unexpected subdomains or test pages. Google says site: results aren’t complete (Google), so finding no staging pages doesn’t prove staging is protected. Visiting the staging address while logged out is the real test.
Passing result: the live address shows your real content; any staging copy asks for a password or login, or is not reachable publicly.
If it fails: a staging site open to the public should be protected with a password or login. Do not remove noindex settings from staging, private or unfinished content; they are there on purpose.
Who fixes it: escalate to your developer or host. Password-protecting a staging environment is a hosting task.

2. WordPress’s search engine visibility setting

On self-hosted WordPress, go to Settings → Reading and look at Search engine visibility.

Why it matters: the box labelled “Discourage search engines from indexing this site” asks search engines not to index the whole site. It is often ticked during a build and forgotten at launch.
Where to check: Settings → Reading. On WordPress.com, go to Settings → Reading → Site Visibility, which offers Coming Soon, Public and Private.
Passing result: on the live site the box is unticked (or, on WordPress.com, the site is set to Public).
What it is not: this setting is a request, not access control. The note under the box says “It is up to search engines to honor this request”, and WordPress’s help text adds that your site “is still visible on the web and not all search engines adhere to this directive”. When it is ticked, the Dashboard’s At a Glance box shows “Search engines discouraged”. An unticked box also does not prove the whole site is indexable; individual pages can still carry their own noindex (check 3).
If it fails: if this is definitely the live site and it should be public, untick the box and save. Leave it ticked on a staging copy.
Who fixes it: usually safe for the owner on the live site. Note the date you changed it.

3. Page-level noindex and HTTP robots directives

Important pages must not tell search engines “noindex”.

Why it matters: a single noindex on a service page keeps it out of Google regardless of how good it is.
Where to check: open the page, view the page source (right-click → View page source) and look in the <head> section for a <meta name="robots" or <meta name="googlebot" tag whose content includes noindex. The word noindex appearing elsewhere, such as in a script or in article text, doesn’t count. In your SEO plugin, open the page in the editor and check its per-page robots setting. In Rank Math, the Advanced tab of the Rank Math panel has a No Index box under Robots Meta (Rank Math must be in Advanced Mode to show that tab). In Yoast SEO, the Advanced tab asks “Allow search engines to show this content in search results?”. Both plugins also have site-wide defaults for each content type. In Search Console’s URL Inspection, look at whether indexing is allowed. A noindex can also be sent as an HTTP header called X-Robots-Tag, which is invisible in the page source; URL Inspection or a header checker will show it (Google).
Passing result: your homepage, service pages and contact page have no robots or Googlebot meta tag containing noindex, no noindex in the plugin settings, and no noindex in an X-Robots-Tag header.
If it fails: if a page you want found is set to noindex in your plugin, switch it to index and save, then re-check the live source. Leave intentional noindex in place on thank-you pages, private content or thin archives you have chosen to exclude.
Who fixes it: plugin setting changes are owner-safe. A noindex sent by a server header is a host or developer job.

4. Robots.txt allows Google to crawl important pages

Your robots.txt file should not block the pages or files Google needs.

Why it matters: robots.txt controls crawling, not indexing. Google says it is “not a mechanism for keeping a web page out of Google” (Google). A blocked URL can still appear in results without a description. And if a page is blocked from crawling, Google cannot see that page’s noindex.
Where to check: visit your domain followed by /robots.txt.
Passing result: no Disallow: / under User-agent: *, and no rule blocking your service pages, CSS or JavaScript. If the file also has a User-agent: Googlebot group, check that group too: Google follows only the most specific group that matches it, so the * rules may not apply to Googlebot at all (Google). A common WordPress default blocks /wp-admin/ while allowing /wp-admin/admin-ajax.php, which is normal.
If it fails: note the rule and who added it (a security plugin, SEO plugin or developer). Do not delete all the rules; some may be deliberate. Private information needs a password or login, not a robots.txt rule.
Who fixes it: escalate unless the rule is clearly set in your SEO plugin’s robots.txt editor and you understand it.

5. Important pages load successfully over HTTPS

Each important page should load at its https:// address without a security warning.

Why it matters: Google prefers HTTPS versions as canonical, and broken certificates put visitors off.
Where to check: type the http:// and https:// versions, with and without www, for your homepage. Open your main service pages.
Passing result: every variation ends on one https:// address, the browser shows no security warning, and pages load normally rather than showing an error. Some browsers, including Chrome, no longer show a padlock, so click the icon beside the address and check the connection is described as secure.
If it fails: a certificate warning, an error page or a version that does not redirect needs attention.
Who fixes it: escalate to your host. Certificate and redirect rules are server tasks.

6. The XML sitemap exists and lists the right pages

Find your real sitemap address rather than assuming one.

Why it matters: a sitemap helps search engines discover URLs. Google is clear that it doesn’t guarantee crawling or indexing (Google).
Where to check: open /robots.txt; it often names the sitemap on a Sitemap: line. Your SEO plugin’s sitemap settings also show the address. Since WordPress 5.5, core WordPress provides a sitemap index at /wp-sitemap.xml, but SEO plugins usually provide their own at a different address, so check rather than guess.
Passing result: the sitemap loads, lists your important pages using their final https:// addresses, and doesn’t list noindexed, redirected or test pages. A sitemap index that links to several smaller sitemaps (for pages, posts and so on) is normal.
If it fails: if pages you want found are missing, check they are published and indexable (check 3). Avoid two systems generating competing sitemaps for the same pages, such as an old plugin still running beside a new one. Google accepts several sitemap files and sitemap indexes (Google), so several files aren’t a problem in themselves. SEO plugins that create their own sitemap usually switch off the core one.
Who fixes it: usually owner-safe through the SEO plugin’s settings. Duplicate or broken sitemap systems: escalate.

7. Search Console agrees about your most important URLs

Use Google Search Console’s URL Inspection on a handful of key pages.

Why it matters: it shows how Google last processed a URL, which is the best evidence you have.
Where to check: in Search Console, paste your homepage, two or three main service pages and your contact page into the inspection bar at the top. Record the overall status (“URL is on Google” or “URL is not on Google”) and, under Page indexing, Last crawl, Crawl allowed?, Page fetch, Indexing allowed?, User-declared canonical and Google-selected canonical. You can also submit your sitemap under Sitemaps.
Passing result: each key page is indexed, and the Google-selected canonical matches the URL you expect.
If it fails: note the reported status exactly. Our guide to pages not indexing explains what the common statuses mean. Requesting indexing can help after a fix, but it does not guarantee inclusion.
If you have no Search Console access: mark this check Not assessable and set up access first.
Who fixes it: inspection is owner-safe. The fix depends on the reason shown. “URL is on Google” means the page can appear, not that it will; the report reflects Google’s last crawl, so use Test live URL after a change.

8. One preferred URL per page, and consistent canonicals

Each page you want found should have one preferred address, and its canonical tag (if it has one) should point to that address.

Why it matters: if the same content is reachable at several addresses, Google chooses one. A canonical tag is a strong signal, not a guarantee; Google can choose a different canonical (Google). Google also says specifying a canonical is “generally not critical”, but if you do, it should be right.
Where to check: view the page source and search for canonical. Compare it with the address in your browser, the sitemap and the Google-selected canonical in URL Inspection.
Passing result: your homepage and service pages each have one canonical tag pointing to their own full https:// address, consistent with the sitemap and your internal links. Some URLs intentionally point elsewhere, such as a duplicate or a version with tracking parameters pointing to the main page. That’s correct, so don’t change it.
If it fails: a page you want found whose canonical points to the homepage, an old domain or a staging address needs correcting. Do not change established permalinks just to add keywords; changing a URL needs a redirect and checks of links, sitemap and canonicals.
Who fixes it: per-page canonical settings in your SEO plugin are owner-safe if you are confident. Template-wide or URL-structure changes: escalate.

Checks 9–14: content, links and images

9. Each page has a clear purpose, title and main heading

Each important page should answer one main customer need, with a matching title and H1.

Why it matters: if ten pages share the title “Services”, neither Google nor customers can tell them apart.
Where to check: look at the browser tab title and the main heading on each page. Your SEO plugin shows the SEO title. View source and search for <h1 to count main headings.
Passing result: each title and H1 is unique and describes the page in plain words, such as the service and the area you cover.
If it fails: rewrite the SEO title in your plugin and adjust the main heading in the editor. If the theme adds a second H1 on every page, that is a template issue.
Who fixes it: titles and headings are owner-safe. Theme template H1s: escalate.

10. Service content answers the customer’s question

Each service page should contain what a customer needs to decide to contact you.

Why it matters: a page with a few lines and a form gives search engines and customers little to go on.
Where to check: read each service page as a customer would. Hypothetical example: a Nottingham electrician’s “EV charger installation” page should say what is included, who it suits, the areas covered, typical timescales, how pricing works and what happens next.
Passing result: the page answers those questions in your own words, without repeating the same paragraphs used on other pages.
If it fails: add the missing answers. Our Content & On-Page SEO page covers pages that overlap or compete.
Who fixes it: owner-safe, and you are best placed to write it.

11. Important pages are linked from relevant places

Your service pages should be reachable from your menu and from related pages.

Why it matters: Google discovers pages largely by following links, and links show what matters on your site.
Where to check: from the homepage, count the clicks needed to reach each service page. Check whether related pages link to each other with descriptive text rather than “click here”.
Passing result: each important service page is in the navigation or linked from the homepage, and from at least one relevant page.
If it fails: add a sentence linking to the relevant service from a related page or guide.
Who fixes it: owner-safe. Menu restructuring on a builder site may need help.

12. Broken internal links and removed URLs

Links on your site should lead to live pages, and removed pages should go somewhere sensible.

Why it matters: broken links waste visitors’ time and can leave Google following dead ends.
Where to check: click through your menu, footer and main buttons. Search Console’s Pages report lists “Not found (404)” URLs. A crawling tool can list broken links across the site.
Passing result: links work, and old service addresses redirect to the closest relevant live page. A page that is truly gone shows a proper “not found” page.
If it fails: update the link in the editor. For removed pages, add a redirect to the most relevant replacement, not automatically to the homepage.
Who fixes it: editing links is owner-safe. Redirect rules are owner-safe through a redirect tool you already use; chains, loops or server rules: escalate.

13. PDFs, menus and price lists versus useful web pages

Information customers need should usually be on a web page, with a PDF as an optional download.

Why it matters: Google can index PDFs, but a PDF-only price list or brochure is harder to read on a phone, harder to link to and easier to let go out of date.
Where to check: list any PDFs linked from your site and what they contain.
Passing result: key service details and prices are on an HTML page; any PDF is a convenience copy, kept up to date.
If it fails: put the essential information on the relevant page and link the PDF from there. Only exclude a PDF from search if it should not be found, for example an outdated version. Excluding a PDF needs an X-Robots-Tag: noindex HTTP header, because a PDF cannot carry a meta tag. Do not block it in robots.txt and expect Google to read a noindex; a blocked file cannot be read.
Who fixes it: moving content into pages is owner-safe. Header rules: escalate.

14. Images: meaningful alt text and sensible sizes

Informative images should have descriptive alt text, and images should be sized for how they are displayed.

Why it matters: alt text helps screen-reader users, and Google uses it with the page content to understand images. Google warns that stuffing alt text with keywords may cause a site to be seen as spam. Oversized images slow pages down.
Where to check: in the Media Library, open important images and look at “Alternative Text”. Check file sizes and dimensions against how large they appear on the page.
Passing result: photos of your work or team have short, accurate descriptions, such as “Newly fitted kitchen with oak worktops in a terraced house” (hypothetical). Purely decorative images should have empty alt text (alt="") so screen readers skip them; in WordPress, leave Alternative Text blank for that image. Images are cropped to the shape they are shown in and compressed.
If it fails: write alt text that describes the image, not a list of keywords. Resize or compress large images. No single file type suits every image; photos, logos and graphics compress differently.
Who fixes it: owner-safe.

Checks 15–20: usability, structured data and maintenance

The site should be easy to read and use on a phone.

Why it matters: many local customers search and call from a phone.
Where to check: open your homepage and main service pages on your own phone. Try the menu, the call button and the enquiry form.
Passing result: text is readable without zooming, the menu opens and closes, buttons are easy to tap, and nothing covers the content.
If it fails: note the page and what went wrong with a screenshot.
Who fixes it: simple content fixes are owner-safe. Layout and menu problems: escalate.

16. Speed and Core Web Vitals evidence

Use real-user data where it exists, not a single test score.

Why it matters: Core Web Vitals measure real-world loading (LCP), responsiveness (INP) and visual stability (CLS). Google’s suggested targets are LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 (Google).
Where to check: Search Console’s Core Web Vitals report shows field data from real visitors, if your site has enough traffic. PageSpeed Insights shows field data at the top, where available, and a single laboratory test below.
Passing result: field data for your key pages is in the “good” range. Google assesses this at the 75th percentile, meaning 75% of real visits were at least that good (Search Console Help).
If there’s no field data: smaller sites often have none. Record the field assessment as Not assessable, then record the lab findings separately. A good lab test doesn’t count as a field pass.
What a problem means: one lab test varies between runs and is a diagnostic, not a verdict. A perfect 100 score is not required to rank. Slow pages can come from hosting and server response, caching, large images or third-party scripts such as chat widgets, maps and booking tools.
If it fails: record which pages and which metric. Do not disable plugins or scripts blindly; forms, bookings, cookie consent or tracking may depend on them.
Who fixes it: image compression is owner-safe. Caching, hosting and script changes: escalate. Our Technical SEO service covers speed and Core Web Vitals problems.

17. Page-builder output and unnecessary assets

Check what your theme or page builder actually outputs, not just how it looks in the editor.

Why it matters: builders such as Elementor or Divi are not bad for SEO in themselves, but any build method can produce problems such as headings chosen for size rather than order, content duplicated for mobile and desktop, or scripts loaded on pages that do not use them.
Where to check: view the source of a service page and search for <h1. To check for duplicated content, use the page as a visitor would: on a desktop and on a phone, look for the same section appearing twice. A sentence repeated in the source isn’t proof on its own, because it can also sit in structured data, scripts or hidden menus. In PageSpeed Insights, look at the diagnostics for unused CSS and JavaScript.
Passing result: one H1, a logical heading order, each section visible once to the visitor, and no obvious heavy unused files.
If it fails: heading levels can usually be changed in the builder’s settings for that widget. Duplicated containers and asset loading are template issues.
Who fixes it: heading levels are owner-safe. Template and asset changes: escalate, and test on staging first.

18. Structured data matches what is visible

Any structured data on your site should describe what visitors can actually see.

Why it matters: structured data can help Google interpret a page, but it must agree with visible content.
Where to check: run a page through Google’s Rich Results Test, which shows which Google rich results the page’s markup could produce, and the Schema Markup Validator, which checks all schema.org markup without Google-specific warnings. If you see several Organization or LocalBusiness items, check what each describes. Separate items for genuinely different things, such as two branches, are fine. Two plugins describing the same business differently, with a different name, phone number or address, is the problem to fix.
Passing result: valid markup, no conflicting descriptions of the same business, and the business name, phone and prices matching the visible page (Google).
What not to expect: valid markup does not guarantee review stars, FAQ results or AI citations. Do not add extra Organization, WebSite or Article entities just to improve a plugin score.
If it fails: note which plugin outputs each item. Don’t delete markup just because there’s more than one item.
Who fixes it: escalate if two systems output conflicting markup.

19. Business details and enquiry routes work everywhere

Your business name, phone number and email should match across the site, and every enquiry route should work.

Why it matters: a wrong phone number in the footer or a broken form loses enquiries, whatever your rankings.
Where to check: compare the header, footer, contact page, structured data and your Google Business Profile. Tap the phone link on a phone. Send a test enquiry through each form and confirm it arrives.
Passing result: details match everywhere, phone links dial the right number, and test enquiries arrive.
If it fails: correct the visible text and clickable tel: links. Check your structured data too.
Who fixes it: text edits are owner-safe. Forms that do not deliver mail: escalate to your developer or host.

20. A repeatable maintenance and monitoring record

Keep a short, dated record of changes and checks.

Why it matters: when something drops, the first question is “what changed and when?”
Where to check: your own log, plus Search Console and your WordPress update history.
Passing result: you can say when plugins, themes and core were last updated, when backups last ran and when you last looked at Search Console.
What to do: take a backup before material changes and use staging where possible. Never restore an old backup over a live site that has taken new bookings, enquiries or orders since, because that data can be lost; ask your host or developer instead. A plugin score is not a ranking guarantee or a substitute for checking the live page.
Who fixes it: owner-safe. If you’d rather hand routine maintenance over, our WordPress care plan covers WordPress updates, routine backups, security checks and small website changes. It’s a care service, not a substitute for SEO work.

Checklist summary

Check	Priority	Next action
1. Intended public site vs staging	Critical	Protect staging; escalate
2. Search engine visibility setting	Critical	Untick on live site only
3. Page noindex and X-Robots-Tag	Critical	Fix plugin setting; headers escalate
4. Robots.txt crawl access	Critical	Note rule; escalate
5. HTTPS and working pages	Critical	Host fixes certificate/redirects
6. XML sitemap	High	No competing generators; correct contents
7. Search Console inspection	Critical	Record status and canonical
8. Preferred URL and canonical	High	Correct canonical; no casual URL changes
9. Purpose, title and H1	High	Rewrite unique titles
10. Useful service content	High	Add missing answers
11. Internal links	High	Link from related pages
12. Broken links and removed URLs	High	Fix links; relevant redirects
13. PDFs vs web pages	High	Put key info on page
14. Images and alt text	High	Describe, resize, compress
15. Mobile usability	Important	Screenshot and report
16. Speed and Core Web Vitals	Important	Field data first; lab separately
17. Page-builder output	Important	Fix headings; test templates
18. Structured data	Important	Resolve conflicts; match content
19. Business details and enquiries	Important	Test every route
20. Maintenance record	Important	Back up; keep a log

When to fix it yourself and when to ask for help

If you have found a confirmed critical problem you cannot safely fix, such as a server-level noindex, a robots.txt rule you do not understand or a canonical pointing elsewhere, a defined technical SEO correction may be enough. If several things look wrong and the cause is unclear, an SEO audit with implementation is the broader option. If everything passes, you may not need paid help at all; keep your log and repeat the checks after major site changes.

By David, founder of SEO Agency in Nottingham.

WordPress SEO checklist for UK small businesses: 20 checks you can do yourself