Auditing a small WordPress website starts with a few practical questions: Can search engines access the important pages? Is each page clear and useful? Can visitors find what they need?
This checklist provides a starting point for reviewing a client site, recording issues, and deciding what to fix first. It separates checks you can perform in WordPress and your browser from checks that benefit from Google Search Console or a dedicated SEO tool.
Before you start: define the scope
Start by agreeing on what the website needs to achieve. For a small service business, that might be qualified enquiries, booked consultations, or calls from local customers. This goal helps you decide which pages and problems deserve attention first.
Record these details before checking individual pages:
- Main goal: What action should a visitor take?
- Target audience: Who is the site for, and which locations does the business serve?
- Priority pages: List the homepage, key service pages, and the contact or booking page.
- Available access: Confirm whether you can use WordPress, Google Search Console, and any existing analytics reports.
- Recent changes: Note any redesign, domain move, URL changes, or plugin changes that could help explain current issues.
- Permission to make changes: Separate the audit from implementation. Agree with the client before changing settings or content.
Choose a manageable starting set
For an initial manual review, start with five to ten important URLs. Include different page types rather than checking only the homepage. This is a starting sample, not a complete site audit.
For example, a local service business might start with its homepage, three service pages, an about page, and a contact page. This is an illustrative example, not a reported client result.
Create an evidence log
For each finding, record the URL, what you checked, what you observed, the date, and a screenshot or report where useful. Add the proposed action and who needs to approve it. If you cannot verify something because access is missing, mark it as “not checked” rather than treating it as a pass.
Check crawling and indexing
What to check: Can search engines reach the pages you want people to find, and are those pages eligible for indexing? A page opening in your browser does not prove that it is indexed.
In WordPress, open Settings → Reading and check Search Engine Visibility. For a public site intended to appear in search, investigate an enabled “Discourage search engines” setting. Keep deliberate restrictions on staging sites and unfinished launches. This setting is not password protection. See the WordPress Reading settings documentation.
Check priority pages for unintended noindex directives and review robots.txt for crawl restrictions. These serve different purposes: blocking crawling is not a reliable way to remove a URL from search, and Google must be able to crawl a page to see its noindex directive. Confirm the intended behaviour before changing either.
With Search Console access, inspect a priority URL. Record the reported indexing status and, where available, Google’s selected canonical URL. Use the live test to investigate current accessibility; a successful live test does not mean the page is already indexed or guarantee that it will be. Refer to Google’s URL Inspection guide and its page availability checks.
Record: URL, intended indexing status, observed restriction, and supporting evidence. Treat an accidental restriction on a key service page as urgent. A deliberately excluded utility page is not automatically a problem.
A setup example from SiteOps Lab
During SiteOps Lab’s initial setup, the owner checked the WordPress visibility setting, the homepage source, and the sitemap in the browser. The visibility restriction was off. The supplied robots meta tag contained max-image-preview:large, without noindex, and robots.txt restricted the admin area rather than public pages.
The page sitemap listed just the root URL, even though the planned pages were still drafts. WordPress can add that URL automatically when the homepage displays the latest posts. A page sitemap therefore does not, by itself, prove that a draft page has been published. This behaviour is documented in the WordPress sitemap implementation.
These were setup checks on this site, not a client audit or evidence of Google indexing. HTTP-level indexing directives and Google’s actual index status had not yet been checked.
Review titles, headings, and page content
Review each priority page’s HTML title, main visible heading, and opening paragraphs. Titles should identify the page clearly; headings should help readers understand its structure. Google may generate a search title from several sources, so the displayed search result is not guaranteed to match your title exactly. See Google’s SEO Starter Guide.
For a service page, ask: What is offered? Who is it for? Where is it available, if location matters? What should a visitor do next? Mark vague claims, outdated details, and unanswered customer questions. Add useful detail rather than repeating a keyword to reach a target count.
Illustrative rewrite: “Services” could become “WordPress Maintenance for Small Businesses” when that accurately describes the page. The improvement is clarity, not a promise of higher rankings. Record the current wording, proposed wording, and the client information needed to support it.
Check internal links and navigation
Follow a visitor’s path from the homepage to a service page and then to the contact or booking page. Open the mobile menu, footer links, and important calls to action. Note broken destinations, outdated links, empty menus, and routes that make it difficult to take the next step.
Use descriptive link text and ordinary crawlable links for important navigation. Relevant internal links help visitors and search engines discover related pages. Google’s SEO Starter Guide explains these principles.
Record: The source page, link text, destination, and observed problem. A broken contact link on a core service page deserves attention before a minor footer wording change. If you test a form or booking flow, agree on a test procedure so the client can distinguish your submission from a real lead.
Review mobile usability and page speed
Open the priority pages at a narrow screen width and, if possible, on a real phone. Check that text stays readable, controls are usable, and content does not overflow horizontally. Test the menu and the main enquiry route rather than judging the page from a screenshot alone.
Run public priority URLs through PageSpeed Insights. Separate real-user field data from the simulated Lighthouse test. A small or new site may lack enough field data; that absence is not a failing score. Record the tested URL, device mode, date, and whether the data describes that URL or the wider origin. See Google’s PageSpeed Insights documentation.
Core Web Vitals assess loading, responsiveness, and visual stability through LCP, INP, and CLS. Use them to investigate the visitor experience rather than treating a single score as the whole audit. Google’s Web Vitals guide explains the metrics.
Next action: Select a specific issue from the report, such as an oversized image or unexpected layout movement. Make an approved change and retest under comparable conditions. Avoid installing several optimisation plugins at once: it makes both troubleshooting and attributing improvements harder.
Check images and accessibility basics
Check whether meaningful images have useful text alternatives. Describe the information an image contributes in its context. Decorative images generally need an empty alt attribute; linked images need an accessible name that conveys their function. Do not fill every image with keywords. Use the W3C alt-text decision tree to distinguish these cases.
For an audit screenshot, explain the relevant finding in the article text as well. Remove credentials, personal details, and confidential client information before publishing it.
Try moving through the page with the keyboard. Can you see which link or control has focus? Can you open and close the menu and reach the form fields? Record any blocked task for further investigation. These checks support usability, but they are not a complete accessibility audit or a guarantee of compliance.
Turn findings into a prioritized action list
A useful client handover explains the problem, the evidence, and the next action. Use the following working priorities, adjusting them to the site’s goals and the strength of your evidence:
- Fix first: Confirmed problems preventing an important task, such as an unavailable service page, a broken enquiry route, or unintended noindex on a priority page.
- Plan next: Improvements to clarity and navigation, such as a vague service title or a useful page that is difficult to find.
- Investigate: Findings that need access, more evidence, or an explanation from the client before changing anything.
Give each action an owner, an effort estimate, and a verification step. For example: “Replace the broken contact link on the maintenance page; then open it on desktop and mobile and confirm the agreed enquiry route works.” This is an illustrative task, not a finding from a tested client site.
After implementation, record what changed and retest the original issue. Separate a verified technical fix from later search or business outcomes. Fixing a setting does not establish that rankings or enquiries have improved.
When to use a dedicated SEO tool
A manual review of a few pages can reveal important problems. A crawler becomes more useful when you need to review many URLs, look for repeated issues across templates, or compare findings between audits. Choose a tool around the work you need to repeat and the budget available.
Treat automated findings as items to verify. A warning needs context: which pages are affected, whether the behaviour is intentional, and what it means for visitors or search access. A tool’s overall score is not a substitute for that judgement.
Start your next audit by selecting the priority URLs and opening an evidence log. Work through the checks above, then give the client a short, actionable list with clear ownership and verification steps.