A client once asked us why six months of blogging had produced almost nothing. The answer took eleven minutes to find. Their blog template carried a sitewide noindex tag left over from a staging environment. Every article they had paid for was invisible to search engines. No amount of writing would have fixed that.
That is the argument for auditing technical health before you commission a single word. Content is the engine, but technical SEO is the fuel line. If it is blocked, the engine will not start no matter how much you pour in. What follows is the sequence we work through, in priority order, because the order matters as much as the checklist itself.
Step one: confirm search engines can reach the site at all
Start at the perimeter. Three files & settings quietly cause more lost visibility than any ranking factor.
- robots.txt. Read it line by line. A stray
Disallow: /is rare but catastrophic. More common is a disallowed directory that also holds CSS or JavaScript, which stops Google rendering the page properly. - Meta robots & X-Robots-Tag. Check the rendered HTML, not the source template. Check the HTTP headers too, since a noindex delivered at server level never appears in the markup.
- Canonical tags. Every page should either point at itself or deliberately at a chosen master version. Sitewide canonicals pointing at the homepage are a surprisingly frequent theme fault.
Then pull the site through a crawler & compare the crawlable page count against the number of pages you believe you have. A large gap in either direction is your first real finding. Too few crawled pages usually means orphaned content or broken navigation. Too many usually means parameter URLs, faceted filters or pagination generating near infinite variations.
Step two: separate indexation problems from crawling problems
People conflate these constantly. Crawling is whether a bot can fetch the page. Indexing is whether it decides the page deserves storage. A page can be crawled perfectly & still never index because the content is thin, duplicated or judged redundant.
Google Search Console's page indexing report is the fastest diagnostic here. Work through the exclusion reasons rather than skimming the total:
- Discovered, currently not indexed. Usually a quality or crawl-priority signal. The site is asking for attention it has not earned yet.
- Crawled, currently not indexed. The page was fetched & rejected. Look hard at whether it duplicates something you already publish.
- Duplicate without user-selected canonical. You have near identical pages competing. Consolidate them.
- Alternate page with proper canonical tag. Usually healthy, but verify the canonical target is the page you actually want ranking.
Index bloat is more damaging than most teams expect. When thousands of low-value URLs sit in the index, the pages you care about compete against your own noise for attention.
The fix is rarely mass deletion. It is deciding, per URL pattern, whether the page should be indexed, canonicalised to a parent, noindexed but crawlable, or blocked entirely. Write that decision down as a rule per template, not per page, or the cleanup will not survive the next site update.
Step three: check what the renderer actually sees
Modern sites assemble a lot of content in the browser. If your product descriptions, reviews, internal links or main headings only appear after JavaScript executes, you are relying on a rendering step that is slower & less reliable than the initial fetch.
Use the URL Inspection tool & view the rendered HTML rather than the raw response. Ask three questions. Is the primary heading present? Is the body copy present? Are the internal links present as real anchor elements with href attributes? Links built from click handlers on div elements are not links, & search engines will not follow them.
Where critical content depends on client-side rendering, the practical answers are server-side rendering, static generation, or at minimum ensuring the important text ships in the initial HTML payload. This is one of the areas where our technical SEO work tends to unlock the largest gains, because the content already exists & is simply not being seen.
Step four: treat speed as a user metric, not a score
Chasing a green performance score is a distraction. Core Web Vitals matter because they describe real frustration: how long until something useful appears, how quickly the page responds to a tap, & whether the layout jumps while you are reading.
Work from field data first. Lab tools are useful for diagnosis, but field data reflects your actual visitors, on their actual devices & connections. In Nepal that distinction is significant. A site that feels instant on office fibre in Baluwatar can feel sluggish on a mobile connection outside the valley, & mobile is where most of the traffic sits.
The highest-leverage fixes are consistent across almost every audit we run:
- Serve correctly sized, modern-format images & give every image explicit dimensions.
- Preload the largest above-the-fold asset & stop lazy-loading it, since lazy-loading the hero image directly damages the largest contentful paint.
- Audit third-party scripts ruthlessly. Chat widgets, heat maps, duplicate analytics tags & abandoned tracking pixels accumulate over years & nobody removes them.
- Reserve space for anything injected after load, including banners, ads & cookie notices, so the layout stays still.
Step five: make the internal link graph do some work
Internal linking is the most underused technical lever available, partly because it sits awkwardly between the content team & the development team. Search engines infer importance from how a site links to itself. If your most commercially valuable page is reachable only through a footer link, you are telling a story you did not intend.
Map click depth from the homepage. Anything important sitting four or five clicks deep needs promotion. Then check anchor text. Navigation links are generic by necessity, but in-body links should describe the destination in the words a customer would use. Finally, hunt for orphan pages, meaning URLs present in the sitemap with no internal links pointing at them. They are usually old campaign landing pages or articles published outside the normal workflow.
Step six: add structured data where it changes the result
Structured data does not improve rankings by itself. It improves how your result is understood & displayed, & increasingly it helps machine readers extract facts cleanly. Prioritise the types that map to what you genuinely offer: Organization, LocalBusiness, Service, Article, FAQPage, Product & BreadcrumbList.
Two rules keep you out of trouble. Only mark up content that is visible on the page, & validate every template rather than one sample URL. Invalid markup at template level multiplies instantly.
Turning the audit into a plan
An audit that produces a 200-item spreadsheet produces nothing. Sort findings into three buckets: things that block indexing, things that suppress performance, & things that are genuine polish. Ship the first bucket this sprint, schedule the second, & be honest that the third may never be worth the developer hours.
Re-crawl four weeks after the fixes land & compare like for like. Technical SEO is a maintenance discipline, not a project with an end date. Every redesign, plugin update & CMS migration reintroduces risk.
If you would rather not run this yourself, we do it as a fixed-scope engagement. Look at how we structure the work across our service lines, check current pricing, or tell us what is broken & we will tell you honestly whether it needs an audit or a single afternoon.