A small business website can collect plenty of visits and still produce nothing useful. Technical SEO is about making sure search engines can find, read and understand the right pages. Measurement tells you whether those pages lead to the outcome you care about. Setting up both at launch is much cheaper than discovering the gaps six months later.
This guide is a checklist in the order we would work through it.
Decide what a good visit leads to
Before you open a dashboard, write down what a successful visit should end in. For a service business it is usually a relevant enquiry with enough detail for a real conversation. For a resource library it may be a reader finding the guide they needed.
Then map the path to that outcome: someone finds a service page, reads how you work, checks an example or a guide, and gets in touch. Note what they need to decide at each step. This map links content, navigation and measurement, and it stops you optimising one number while the real problem sits elsewhere, such as an unclear offer or a broken form.
Make important pages easy to reach
Start with a page inventory. Every important page should have one clear purpose and be reachable from the navigation or from links inside related pages. A service page explains one service. A guide answers one question in enough depth to be useful. Avoid publishing near-identical pages just to target more phrases. One good page usually beats five thin ones.
Then check the links themselves:
- Use descriptive link text so people know where a link goes. Google's SEO starter guide makes the same point: link text tells users and Google something about the destination.
- Make sure no important page is an orphan with nothing linking to it.
- After renaming or removing a page, fix the old links and redirect the old address.
- Keep an XML sitemap of the pages you want indexed and submit it in Google Search Console.
A sitemap helps search engines find your URLs, but visitors still depend on a navigation that makes sense. Google's sitemap documentation has three details worth knowing. List only the preferred, canonical address of each page. Google uses a lastmod date only if it is consistently accurate, so set it to the last real content change and not to the day you built the site. And Google ignores priority and changefreq, so there is no point agonising over them.
Keep the technical signals honest
Give each page a distinct title and description that match what is visible on it. Use headings to structure content, with one main heading per page, instead of using them to make text bigger. Choose one preferred address per page and use it in your links, your sitemap and your canonical tag.
It helps to know what each control does and does not do:
| Control | What it does | A common mistake |
|---|---|---|
robots.txt | Asks crawlers not to fetch certain paths | Using it to hide a page. Google says it is not a mechanism for keeping a page out of search |
noindex tag | Keeps a page out of search results | Blocking the page in robots.txt too, so the crawler never sees the tag |
| Canonical tag | Names the preferred address when content exists at several | Pointing to a page that redirects or returns an error |
| Redirect (301 or 308) | Sends visitors and crawlers to the new address | Chains of several redirects, or temporary redirects left in place |
| Login | Actually restricts access | Believing a "hidden" link is private |
Google's guidance on consolidating duplicate URLs ranks redirects and canonical tags as strong signals and sitemaps as a weak one, and asks you to use one form consistently. In practice that means choosing between www and the bare domain, and between trailing slash and none, once, and redirecting everything else.
Structured data (schema markup) must describe what the page really contains: your organisation, an article, a breadcrumb trail. Google's guidelines say not to mark up content that readers cannot see. One current detail: Google stopped showing FAQ rich results in May 2026, so an FAQ block is worth adding for your readers, not for a special search listing. If you serve customers in a specific city, a complete Google Business Profile with your real address and hours will usually do more for local searches than any code change.
Use Search Console, and read what it says
Verify your site in Google Search Console, submit the sitemap, and inspect your most important page with the URL Inspection tool. It shows whether Google has the page, when it last crawled it and which address it chose as canonical. Google's help page is clear that "request indexing" does not guarantee the page will appear, and that submitting a sitemap is the better route for many pages. If someone audits your site, give them read-only access.
Do not expect instant results. Google's own guide says every change takes time to show up, from hours to months, so judge a change after a few weeks, not the next morning.
Check the experience on a real phone
Open your key pages on an ordinary mid-range phone on mobile data, not office Wi-Fi. Google's Core Web Vitals give three checks: how quickly the main content appears (Largest Contentful Paint, good at 2.5 seconds or less), how quickly the page responds to taps (Interaction to Next Paint, 200 milliseconds or less) and how much the layout jumps while loading (Cumulative Layout Shift, 0.1 or less). Google measures these at the 75th percentile of real visits. PageSpeed Insights reports them for any public URL.
Speed is only part of it. A fast page with a confusing form still loses the enquiry. Walk through the whole task: fill the form in wrongly, read the error messages, submit it properly, read the confirmation. Then repeat it with only a keyboard, check that focus is visible, and confirm every field has a clear label. Images that carry information need useful alt text. These checks find friction that a visual review misses.
Create a small GA4 event plan
Google Analytics 4 records page views on its own. The events that matter are the few that mark real steps toward your outcome. In GA4 you can mark an event as a key event, and the sensible habit is to mark only the two or three that show real business value. Marking every button click buries the signal. Examples:
| Event name | When it fires | Why it matters |
|---|---|---|
cta_start_project | A "Start a project" button is clicked | Intent to enquire |
whatsapp_click | A WhatsApp link is opened | A direct conversation started |
contact_form_handoff | A valid form is handed to WhatsApp or sent | A completed enquiry |
Name events consistently and write down exactly when each one fires. Do not send names, phone numbers, email addresses or message text to analytics. You do not need them to measure, and they create privacy obligations. If you switch analytics on, update your privacy policy and check whether your visitors' location requires a cookie consent banner.
Test each event once from start to finish. A completed enquiry should be counted once, and a failed validation should not count at all. Your own test visits should be filtered out or easy to recognise, and GA4's DebugView will show events as they arrive.
Mistakes we would check for first
- A
noindextag or a blanket robots.txt block left over from the staging site. - A sitemap that lists redirected, noindex or error pages.
- The same title or description copied across many pages.
- A cookie banner or pop-up that covers the page on a phone.
- Tracking that counts the same enquiry twice, for example once on the click and again on a thank-you page.
- Pages that appear only after JavaScript runs, so the first HTML is empty. View the page source, not just the rendered page.
Turn the numbers into decisions
Record a baseline before changing several things at once. Note which pages bring relevant visits, where people continue and where they drop off. Look at a period long enough for your traffic. With small numbers, week-to-week movement is mostly noise. Combine the figures with direct checks, such as reading the enquiries you actually received.
Pick one question per round. Perhaps visitors understand the service but miss the contact link, or a guide attracts readers who need a related explanation. Make one targeted change, write down why, and look at the result. Include maintenance in the same rhythm, because new content can quietly add broken links, duplicate titles or missing events.
Our GROWTH service covers technical SEO, analytics and content. If you are planning a new site, measurement is far easier when it is part of the project scope from the start, and our guide to SEO, AEO and GEO explains where the newer labels fit. To have your site reviewed, get in touch or email contact@wisvera.com.
Written by WISVERA, a founder-led studio. We use AI tools when drafting and check each guide against the sources it links to before publishing. Found a mistake or have a question? Email contact@wisvera.com.
