Technical SEO Services in Durban & KZN, Built for Crawling, Rendering and Indexing

Server Log Analysis

Third-party crawl simulators show you what a crawler could see. Server logs show what Googlebot actually requested, how your server answered, and where the crawl budget went. With log access, we segment requests by bot user agent, status code, URL pattern, template and response time, which gives a factual picture of crawl behaviour instead of a simulated one.

We check status code distribution across your priority templates and separate valid requests from redirects, soft errors, server errors and dead URLs. On large sites, crawl budget often leaks into faceted navigation, filter combinations, tracking parameters, internal search pages and session-based URLs, and we trace exactly how much of it goes there. The output is a list of which URL rules, redirects or server responses need to change, and why.

DOM Render-Path and JavaScript Hydration

Google crawls raw HTML first and queues JavaScript execution separately. If your copy, links, canonical tags or structured data only appear after JavaScript runs, and something in that rendering step breaks, Google can end up indexing a page that looks nothing like what a visitor sees in their browser. The two versions of the page, raw and rendered, can genuinely disagree with each other.

We pull the raw HTML the origin server returns and compare it against the fully rendered DOM after JavaScript execution. The diff shows missing copy, missing links, missing or delayed metadata, canonical tags that change mid-render, duplicate elements, and schema that either loads too late or never loads. The fix depends on the framework and deployment: server-side rendering, static generation, pre-rendering, or a narrower fix at the component level. We name the specific one your codebase needs, not a generic recommendation to “improve rendering.”

Index Control and Link Graph Engineering

A robots.txt rule and a noindex directive do different jobs, and mixing them up causes real damage: block a page in robots.txt before Google reads its noindex tag, and that page can stay visible in the index indefinitely because Google never gets the chance to see the tag telling it to leave. We audit parameter canonicalisation, canonical tags and headers, XML sitemap membership, robots.txt, robots meta directives, X-Robots-Tag headers, internal links and HTTP status codes together, because they only work as a system.

We also model your internal link structure as a directed graph rather than a flat list. That surfaces orphan pages, click depth that is too deep for Google to bother with, redirect-dependent paths, and templates that quietly pull internal PageRank away from the pages you actually want to rank. You get changes at the template level, not a spreadsheet of individual links to add by hand.

Structured data gets checked in the same pass: whether the raw and rendered states expose the same schema, whether your entities connect into something coherent, and whether the markup actually matches what is on the page.

Core Web Vitals

We check your current Core Web Vitals against field data where it exists, then use lab and staging tests to find which specific elements are causing failures.

These thresholds apply at the 75th percentile of page loads, scored separately for mobile and desktop. We trace every failure to the template, component, asset or execution path responsible. A ticket might target the LCP resource and server response, the JavaScript task blocking INP, or the missing size reservation causing CLS.