Technical SEO Checklist for Kenyan Websites

Technical SEO Checklist for Kenyan Websites: A Practical Guide

A website can look modern, publish useful content, and still remain almost invisible on Google.

The problem is often not the colour palette, the number of blog posts or the wording of the homepage. It is the technical layer underneath. Important pages may return the wrong status code, links may disappear when JavaScript fails, a staging instruction may leave the whole site set to noindexor several versions of the same page may compete to become canonical.

For a Kenyan business, these faults have a direct commercial cost. A service page that cannot be indexed cannot generate an organic enquiry. A mobile page that shifts while someone tries to tap the WhatsApp button can lose a qualified prospect. An ecommerce filter that creates thousands of weak URLs can waste crawl attention while the product pages that matter remain poorly connected.

This technical SEO checklist for Kenyan websites helps you inspect those risks in the right order. The goal is not to collect the largest possible number of errors. It is to find the smallest set of technical constraints that prevent search engines and customers from reaching the pages that create revenue.

Quick answer

A technical SEO audit checks whether search engines can access, crawl, render, index, and understand the pages a business wants customers to find. It should review HTTP responses, robots directives, sitemaps, canonicals, redirects, internal links, mobile rendering, JavaScript, Core Web Vitals, structured data, and security.

Fix the failures that remove important pages from search first. Then address duplication, architecture and mobile experience. Performance warnings and optional enhancements come later unless they are already hurting users or conversions.

Key takeaways

• A page must be accessible and return a valid response before content optimisation can help it.

• robots.txt controls crawling. It is not the correct tool for reliably removing a page from Google's index.

• A sitemap helps discovery, but it does not guarantee crawling or indexing.

• Canonicals, redirects, internal links, and sitemap entries should point toward the same preferred URL.

• Google uses the mobile version of a page for indexing and ranking, so critical mobile content and links cannot be treated as optional.

• Core Web Vitals measure real user experience, but they are one part of a larger search and conversion system.

• Structured data helps describe visible content. It does not create authority or guarantee a rich result.

• Audit findings should be prioritised by affected page, business value, scale and risk, not by the tool's warning count.

What a technical SEO audit should answer

Google describes Search as a sequence that includes crawling, indexing and serving results. A technical review should therefore answer five practical questions:

1. Can search engines discover the URL?
2. Can they access and render the page correctly?
3. Is the page allowed and suitable to be indexed?
4. Can Google understand which version is preferred and how it relates to the rest of the website?
5. Can a real visitor use the page comfortably enough to take the intended action?

The first four questions affect organic discoverability. The fifth protects the business outcome. A technically indexable page that is unusable on a modest mobile connection may still waste the visibility it earns.

Technical SEO is therefore not a developer-only exercise. Marketing, content, development and management all have a role. The marketer defines which pages matter. The developer fixes the implementation. The content owner protects meaning and internal relationships. Management decides which risks receive time and budget.

If you need a wider review covering content, local visibility and measurement as well, use the SEO audit checklist for Kenyan businesses as the diagnostic starting point.

Start with business-critical pages

Do not begin by exporting 5,000 warnings from an audit platform. Begin with the pages the business cannot afford to lose.

For a Nairobi professional-services company, that may be the homepage, core service pages, location pages and contact route. For a Kenyan ecommerce store, it may be category pages, product pages, the cart and checkout flow. A hospitality business may depend on accommodation pages, location information and the booking path.

Create a priority set that includes:

• the homepage;
• every main service or category page;
• high-value product pages;
• location pages for genuine staffed locations or service areas;
• pages already receiving organic impressions or conversions;
• pages connected to paid campaigns;
• the contact, quotation, booking or checkout journey.

Check these URLs individually in Search Console before judging the site from a crawler summary. The URL Inspection tool and Search Console reports can show whether Google knows the URL, which canonical it selected and whether a crawl or indexing problem exists.

This business-first approach also prevents a common mistake: spending hours cleaning low-value tag archives while the page responsible for most qualified enquiries returns a redirect chain or carries an accidental canonical to another URL.

Check access, crawling and indexation

A page cannot compete in search if Google cannot access or index it. Google lists a successful HTTP response, accessible content and indexable content among its basic technical requirements for Search.

Check the following for every priority URL:

• The URL loads without authentication or a development password.
• The server returns 200 OK for a genuine working page.
• The page is not blocked for Googlebot by a firewall, CDN rule or bot-protection setting.
• The page does not contain a noindex directive unless exclusion is intentional.
• The canonical points to the correct preferred URL.
• The rendered page contains the main content, headings and crawlable internal links.
• Search Console does not report a conflicting exclusion reason.

Do not treat “Crawled, currently not indexed” as one universal diagnosis. It can reflect weak or duplicative content, canonical uncertainty, rendering problems, poor internal discovery or a page Google does not currently consider useful enough to index. Inspect the URL, its internal links, content purpose and selected canonical before changing technical settings.

Likewise, do not request indexing repeatedly without repairing the cause. A recrawl request can invite Google back. It cannot make a weak, duplicate or inaccessible page worthy of inclusion.

Audit status codes and redirects

HTTP status codes tell browsers and crawlers what happened when they requested a URL. Incorrect responses can keep removed pages in limbo, hide failures behind soft errors or send authority through unnecessary chains.

Google recommends permanent server-side redirects when a URL has permanently moved. Its redirect guidance identifies 301 and 308 as permanent signals.

Audit for:

• redirect chains such as old URL to temporary URL to final URL;
• redirect loops;
• internal links that still point to redirected addresses;
• mass redirects to irrelevant destinations;
• “soft 404” pages that return 200 while displaying no useful content;
• expired campaign and product URLs without a clear retention policy;
• server errors affecting important landing pages.

When consolidating two overlapping articles, redirect the weaker URL to the stronger combined resource and update internal links to the final destination. This is the correct treatment for Tabala's two older technical SEO articles, which overlap heavily and should support one authoritative guide.

Review robots.txt and noindex directives

robots.txt and noindex solve different problems.

Google's robots.txt guidance explains that the file controls which URLs a crawler can access. It is mainly a crawl-management tool, not a reliable method for keeping a page out of search results.

The noindex rule tells a search engine not to include an accessible page in its index. Google must be able to crawl the page to see that instruction. If the same URL is blocked in robots.txt, Google may never read the noindex directive.

Check that:

• production pages are not accidentally blocked by a staging rule;
• CSS, JavaScript and image resources needed for rendering are accessible;
• internal search results, account areas and other low-value spaces follow a deliberate policy;
• noindex appears only on pages the business genuinely wants excluded;
• PDF or non-HTML exclusions use an appropriate X-Robots-Tag header where necessary;
• removal requests are not being used as a permanent substitute for correct indexing controls.

Google's official noindex documentation is particularly important during a redesign or migration. One inherited setting can remove an entire section from search even when the pages look normal to logged-in staff.

Validate XML sitemaps and internal architecture

An XML sitemap is a discovery aid. It is not an instruction that forces Google to index every listed page.

Google says a sitemap provides information about important pages and files, and can help with larger, newer or media-heavy sites. Strong internal linking still matters because crawlers discover and interpret pages by following links.

Review the sitemap for:

• only canonical, indexable URLs that return 200;
• no redirected, 404, noindex or duplicate parameter URLs;
• accurate lastmod values when the CMS can maintain them properly;
• separate sitemap indexes where site scale justifies them;
• submission and processing status in Search Console;
• automatic updates when content is published, removed or consolidated.

Then inspect the website architecture. Important pages should be reachable through normal crawlable links, not only through a search box, a JavaScript-only filter or an orphaned sitemap entry.

Google's link best practices recommend crawlable links and meaningful anchor text. For users, the same practice creates a clearer next step. A guide about website speed should connect naturally to mobile experience, technical audits and the relevant service, not sit alone in the archive.

For the reader-facing optimisation layer, Tabala's on-page SEO guide explains how headings, page focus and visible content work alongside the technical foundation.

Fix canonical and duplicate URL conflicts

Duplicate content is often a URL-management problem, not an accusation of plagiarism.

The same product or article may be available through HTTP and HTTPS, uppercase and lowercase paths, tracking parameters, print versions, category paths or filtered URLs. Google groups duplicates and selects a representative canonical. The site's signals should make that choice consistent.

Google treats redirects and rel="canonical" annotations as strong canonical signals, while sitemap inclusion is weaker. Its canonical URL guidance also warns against sending mixed signals.

Check that:

• every indexable page has a self-referencing canonical where appropriate;
• canonicals use absolute, final HTTPS URLs;
• internal links point to canonical URLs;
• sitemap entries match the canonicals;
• redirected pages do not remain in the sitemap;
• parameter, sort and filter combinations follow a deliberate policy;
• near-duplicate location pages contain genuinely distinct local value;
• old and new URLs are not both left indexable after a migration.

Do not canonicalise a page to another URL merely because the keywords look similar. Canonicals are for duplicate or substantially equivalent content. If two pages serve different user needs, improve their distinction and internal roles. If they answer the same need, consolidate them properly.

Inspect mobile content and JavaScript rendering

Google uses the mobile version of a site's content for indexing and ranking. Its mobile-first indexing guidance recommends equivalent primary content, metadata, structured data and meaningful image information across mobile and desktop.

Test priority pages on a real phone as well as in a responsive desktop preview. Check whether:

• the same essential content appears on mobile;
• navigation exposes important service and category pages;
• accordions and tabs remain accessible in the rendered HTML;
• buttons are large enough to tap and do not overlap;
• forms work with common Kenyan phone-number formats;
• WhatsApp, call, booking and M-Pesa-related journeys work without layout obstruction;
• intrusive pop-ups do not cover the main content;
• images have appropriate dimensions and do not cause horizontal scrolling.

Modern websites often depend on JavaScript. Google can render JavaScript, but the implementation still needs to expose meaningful content and links in the rendered HTML. The official JavaScript SEO basics explains how Google processes and renders eligible pages.

Compare the raw HTML, rendered DOM and Search Console's inspected view when important text or links appear only after interaction. Pay extra attention to single-page applications, client-side error handling, infinite scroll and route changes that do not return meaningful server responses.

For deeper mobile usability and conversion checks, use Tabala's mobile SEO and conversion guide.

Measure Core Web Vitals and page experience

Core Web Vitals measure real-world loading performance, responsiveness and visual stability:

• Largest Contentful Paint (LCP): loading performance, with a good experience at 2.5 seconds or less.
• Interaction to Next Paint (INP): responsiveness, with a good experience below 200 milliseconds.
• Cumulative Layout Shift (CLS): visual stability, with a good experience at 0.1 or less.

These thresholds come from Google's current Core Web Vitals guidance. Use field data where available because it reflects real visits. Lab tools such as PageSpeed Insights and Lighthouse are useful for diagnosis, but one test is not a complete picture of every visitor or template.

For Kenyan audiences, test under realistic conditions. A fast office fibre connection can hide heavy images, third-party scripts and inefficient fonts that become obvious on a mid-range phone or unstable mobile network.

Prioritise fixes that affect both discovery and revenue:

• compress and resize oversized hero images;
• serve modern image formats where appropriate;
• reduce render-blocking resources;
• control third-party tags and chat widgets;
• reserve dimensions for images, adverts and embeds;
• improve server response and caching;
• load non-critical assets only when needed;
• test the actual enquiry and checkout interactions, not only the homepage.

Do not promise that turning every metric green will automatically produce a ranking increase. Page experience is part of a broader system. The commercial benefit may first appear as a faster landing page, fewer accidental taps or a smoother form completion path.

Validate structured data

Structured data provides explicit machine-readable information about visible page content. It can help Google understand the page and make it eligible for supported rich-result formats.

Use the most specific appropriate type, such as Article, Product, BreadcrumbList, LocalBusiness or Organization, and ensure the properties match what a visitor can see. Google's structured data introduction and general guidelines make two points clear: valid markup does not guarantee a rich result, and misleading or hidden information can make the implementation ineligible.

Check that:

• JSON-LD syntax is valid;
• the schema type matches the page purpose;
• names, prices, availability, addresses and dates match visible content;
• markup is not duplicated by multiple plugins or templates;
• every required property for the chosen feature is present;
• warnings are understood rather than ignored automatically;
• the page passes the Rich Results Test where the type is supported;
• structured data remains accurate after content or product updates.

Schema is not a substitute for clear writing, reliable evidence or a coherent entity. If the business wants to improve how search engines and AI systems understand its expertise, the technical foundation should connect to the wider AI Search Optimization service, content structure and entity consistency.

Check HTTPS and security hygiene

Every public business website should use HTTPS consistently. This protects data in transit and avoids browser warnings that destroy trust at the exact moment a visitor is asked to submit details or pay.

Audit for:

• a valid certificate covering the required hostname;
• permanent redirects from HTTP to HTTPS;
• no mixed-content assets loaded over HTTP;
• canonical tags and sitemap entries using HTTPS;
• secure forms and checkout pages;
• no indexable staging, backup or test environments;
• software, plugins and dependencies maintained through a responsible update process.

Security work is wider than SEO, but the two intersect. A compromised site, injected spam page or broken certificate can damage visibility, brand trust and lead generation at the same time. If repairs require a rebuild or structural improvement, Tabala's website development service covers the implementation layer beyond content optimisation.

Technical checks for ecommerce and local businesses

Ecommerce websites

Kenyan ecommerce sites need deliberate control over category filters, sorting, pagination, product variants and out-of-stock URLs.

Check that:

• valuable category pages are crawlable and internally linked;
• filter combinations do not create unlimited indexable URLs;
• product variants have a clear canonical strategy;
• out-of-stock products follow a retention policy based on whether they will return;
• discontinued products redirect only when a close replacement exists;
• Product structured data matches visible price and availability;
• checkout and M-Pesa payment usability are tested as conversion issues, not mislabelled as ranking signals.

Local and multi-location businesses

For a business serving Nairobi, Mombasa, Kisumu, Nakuru or Eldoret, location pages should represent real differences rather than swap a city name into the same template.

Check that each legitimate location page has:

• a unique purpose and locally useful information;
• consistent business details;
• a working map, phone and enquiry route;
• crawlable links from the main website architecture;
• appropriate local business information where applicable;
• no fake offices or doorway pages created only to target more towns.

The broader local SEO guide for Kenyan businesses explains how the website, Google Business Profile, reviews and local relevance work together.

Free and paid tools

No tool produces a finished strategy by itself. Use each one for the question it can answer.

Start with Search Console and a focused crawl of the priority set. Add heavier tooling when the site's scale or complexity justifies it. If you need an evidence-based starting point, run Tabala's free SEO Visibility Audit before commissioning a deeper implementation review.

Prioritise the fixes

An audit becomes valuable only when it changes the order of work.

Score each finding across four dimensions:

1. Business value: Does the affected page generate leads, sales or strategic visibility?
2. Severity: Does the issue block access or indexation, create duplication, harm users or merely represent an optional enhancement?
3. Scale: Does it affect one low-value URL, one critical template or the entire site?
4. Confidence: Is the diagnosis proven through response testing, rendering and Search Console evidence, or inferred from a generic warning?

Budget and timelines should follow the constraint. Tabala's SEO cost guide for Kenya explains why a five-page local business site and a large ecommerce platform should not receive the same technical scope. The guide to choosing an SEO agency in Kenya can also help you evaluate whether a provider owns diagnosis, implementation and verification rather than delivering a report and disappearing.

Technical SEO checklist

Access and indexation

• Priority URLs load publicly and return the intended response.
• Important pages return 200 OK.
• No accidental noindex, password or firewall block exists.
• Google can render the main content and navigation.
• Search Console exclusions have been reviewed by URL type.

Crawling and architecture

• robots.txt allows access to important pages and required resources.
• XML sitemaps contain only canonical, indexable 200 URLs.
• Important pages have crawlable internal links.
• Orphaned service, category and location pages have been identified.
• Internal anchors describe the destination naturally.

URLs, canonicals and redirects

• Preferred URLs use one consistent HTTPS and hostname format.
• Canonicals, internal links and sitemap entries agree.
• Redirect chains and loops are removed.
• Removed URLs use a relevant redirect, 404 or 410 intentionally.
• Filter, sort, parameter and variant URLs follow a documented policy.

Mobile, rendering and performance

• Mobile pages contain the same essential content and metadata.
• Navigation, forms, calls and WhatsApp actions work on real phones.
• JavaScript-rendered content and links appear in the rendered HTML.
• LCP, INP and CLS are reviewed using field data where available.
• Heavy images, scripts, fonts and third-party tags are prioritised by impact.

Structured data and security

• Structured data matches visible content and the page purpose.
• Supported markup passes the relevant validation test.
• HTTPS is valid and enforced consistently.
• Mixed content and insecure forms are removed.
• Staging, backups and test environments are not publicly indexable.

Frequently asked questions

Final recommendation

Do not judge a technical audit by the number of pages in the PDF or the number of red warnings in a dashboard.

Judge it by whether it identifies the pages that matter, proves the cause, names the owner, orders the fixes and verifies the result after implementation.

Start with access and indexation. Align canonicals, redirects, internal links and sitemaps. Protect the mobile experience. Then improve performance and structured understanding without confusing optional enhancements with critical failures.

If your website is losing visibility, failing to index important pages or producing technical reports that nobody implements, run the free SEO Visibility Audit or review Tabala's SEO services in Nairobi. The goal is not another list of problems. It is a prioritised repair plan tied to qualified traffic and enquiries.