Technical SEO has a reputation for being a list of two hundred ranking factors. It is not. It is a much shorter list of things that stop a search engine finding, understanding, or trusting your pages — and each one is either broken or it is not.

The good news is that a competent audit fits in an afternoon. The order below is by how badly each item hurts when it is wrong.

Part 1 — Can it be found?

Is it actually indexed?

Start here, because everything else is irrelevant if the answer is no.

text
site:yourdomain.com

Roughly the right number of pages? Then open Search Console → Pages and read the excluded reasons. The ones that matter:

  • "Excluded by 'noindex' tag" — usually left over from a staging site. This is the single most damaging technical SEO mistake there is, and it is invisible until you look.
  • "Blocked by robots.txt" — check you have not blocked something important.
  • "Crawled – currently not indexed" — Google saw it and did not consider it worth indexing. That is a content problem, not a technical one.
  • "Duplicate, Google chose a different canonical" — your canonical tags disagree with Google's judgement.

robots.txt

It should be at the root and it should be boring. Two failure modes:

  • Blocking CSS or JavaScript. Google renders your pages; blocking assets makes it see a broken site.
  • Blocking the whole site. Disallow: / from a staging config. Check it after every deploy that touches infrastructure.

⚠ A framework-specific trap worth naming: in Next.js, robots.ts must sit at the root of app/. Inside a route group it is silently ignored and /robots.txt 404s. sitemap.ts happens to work from inside a group, so the two behave differently and it is easy to get wrong — we shipped exactly this bug for three versions.

Sitemap

  • Lists only canonical, indexable, 200-status URLs. No redirects, no noindex pages.
  • Referenced from robots.txt and submitted in Search Console.
  • Split above 50,000 URLs.
  • lastmod is honest. A sitemap claiming every page changed today teaches Google to ignore the field.

Part 2 — Can it be understood?

One canonical per page

Every page declares its own canonical URL. The rules that matter:

  • Self-referencing on normal pages.
  • Absolute URLs, not relative.
  • Consistent with what is in the sitemap and what internal links point at.
  • Paginated pages self-canonicalise. Page 2 is not a duplicate of page 1 and should not claim to be.

The classic failure: http and https, or www and non-www, both resolving and both self-canonicalising. That is two sites splitting one site's authority. Pick one and 301 the other.

hreflang, if you are multilingual

Getting this wrong is worse than omitting it, and most implementations are wrong in one of three ways:

  • The pairs must be reciprocal. If English points at Bengali, Bengali must point back at English. A one-way declaration is ignored.
  • Every page must include itself in its own hreflang set.
  • Include x-default for visitors matching no listed language.

The prerequisite people miss: the slug should be shared between languages. If /post/hosting-guide and /bn/post/hosting-guide share a slug, they can declare each other cleanly. Translate the slug and you have two URLs that must be mapped by hand forever — which is why this site deliberately does not localise slugs.

Structured data that is valid

Structured data does not raise rankings directly. It changes how your result looks — breadcrumbs, FAQ expanders, review stars, article dates — and that changes click-through, which is the point.

What to check:

  • It validates. Google's Rich Results Test. Invalid JSON-LD is not partially read; it is ignored entirely.
  • One @graph, not several loose objects. A <script> containing four top-level objects separated by commas is not valid JSON and no crawler can parse any of it. We shipped exactly that on two pages, for months.
  • The IDs are shared. Your Organization node should have the same @id on every page, so a crawler resolves one entity rather than fifty.
  • It matches the visible page. Marked-up content that a user cannot see is a policy violation.

⚠ Do not publish an aggregateRating you cannot substantiate. A self-assigned five stars with no reviews anywhere on the site is precisely the "spammy structured markup" Google's guidelines name, and it is grounds for a manual action. Google requires the reviews to be real and visible on the page.

Part 3 — Can it be trusted?

https, done properly

  • Valid certificate covering both www and the apex — see free vs paid SSL.
  • http redirects to https in one hop, not a chain.
  • No mixed content.
  • Automatic renewal, monitored externally. Certificate lifetimes shortened to 200 days in 2026, so manual renewal is now a recurring risk rather than an annual chore.

Core Web Vitals

Part of page experience, and a genuine tiebreaker. In 2026 the metric most sites fail is INP. The full treatment is in Core Web Vitals in 2026; the short version is: read field data, not your Lighthouse score, and fix the one metric that is failing.

Mobile

Google indexes the mobile version of your site. Not the desktop one. The mobile page is your site as far as ranking is concerned.

  • Same content on mobile as desktop. Content hidden behind a "read more" is fine; content omitted entirely is not.
  • Same structured data and metadata.
  • Tap targets large enough, text legible without zooming.
  • No horizontal scroll. Test at 320px, not just at your laptop width.

Part 4 — Site architecture

  • Important pages within three clicks of the homepage. Crawl depth correlates with how often a page is recrawled.
  • Internal links use descriptive anchor text. "Read more" tells a crawler nothing; the anchor is one of the strongest on-page signals you control.
  • No orphan pages. A page in the sitemap with no internal links pointing at it is a page you have told Google not to care about.
  • URLs are readable and stable. Words, hyphens, lower case, no session IDs. And once published, do not change them casually — every change costs some accumulated authority.
  • 404s return 404. A "not found" page that returns 200 is a soft 404, and Google will find them and be unimpressed.
  • Redirects are single-hop and permanent where the move is permanent.

Part 5 — The 2026 addition: AI search

A growing share of searches now end in a generated answer rather than a click. You cannot rank in an answer, but you can be cited in one, and the technical requirements are specific.

  • Do not block the AI crawlers unless you have decided you want to be excluded. Check robots.txt for GPTBot, ClaudeBot, PerplexityBot, Google-Extended. This is a business decision with a real trade-off — visibility against your content being used — and it should be a decision, not an accident.
  • Server-render your content. An answer engine that cannot see your text without executing JavaScript often does not see it at all. This is the single biggest technical factor.
  • Answer the question near the top. Systems that extract answers favour a direct response followed by elaboration, not a thousand-word run-up.
  • Use real headings. <h2> questions with direct answers beneath them are the easiest possible structure to extract from — which is also why FAQ sections work.
  • Be specific and verifiable. Numbers, dates, named things. Vague marketing prose is not extractable and does not get cited.
  • Keep your entity data consistent — the same organisation name, address and identifiers across your site, your structured data and your profiles elsewhere.

Notice how much of that list is also just good writing. That is not a coincidence, and it is the most durable thing about it.

The afternoon audit

In order. Stop when you run out of afternoon; the top of the list is where the damage is.

  1. site:yourdomain.com — is the page count roughly right?
  2. Search Console → Pages → read every exclusion reason.
  3. Check for stray noindex. Every time.
  4. Fetch /robots.txt and /sitemap.xml and actually read them.
  5. Confirm one canonical host — http/https, www/non-www.
  6. Spot-check canonical tags on five different page types.
  7. Run three pages through the Rich Results Test.
  8. Read field Core Web Vitals for your top templates.
  9. Open your top page at 320px wide.
  10. Check https, both hostnames, and the redirect chain length.
  11. If multilingual: verify hreflang reciprocity on one pair.
  12. Check the AI crawler rules and decide, deliberately.

If a full audit and the fixes are not something you want to spend the month on, we do this as a service too, in both English and Bangla.

What technical SEO will not do

Worth ending on, because this is where budgets get wasted.

Technical SEO removes obstacles. It does not create demand. A perfectly configured site with nothing worth reading ranks for nothing, and no amount of schema markup changes that.

The realistic model: technical work is a multiplier on content that already deserves to rank. Ten times zero is still zero. Get the technical foundation right once, keep it right, and spend the rest of your effort on the thing people actually came for.

Frequently asked questions

What is technical SEO? The work that lets a search engine find, crawl, render, understand and trust your pages — indexing, canonicals, sitemaps, structured data, https, speed and mobile. It is distinct from content and from links.

How often should I run a technical audit? A full audit twice a year, plus a short check after any significant change — a redesign, a migration, a CMS upgrade, a host move. Most technical SEO disasters are introduced by a deploy, not by drift.

Does structured data improve rankings? Not directly. It changes how your result is displayed — breadcrumbs, FAQ expanders, dates — which improves click-through. Do not publish ratings or reviews you cannot substantiate; that is a policy violation with real consequences.

What is the most common technical SEO mistake? A noindex tag left over from staging. It is invisible on the page, catastrophic in effect, and it happens on real sites constantly. Check for it after every deploy.

Do I need to optimise for AI search separately? Mostly no — server-rendered content, clear headings, direct answers and specific facts serve both. The one genuinely separate decision is whether to allow the AI crawlers in robots.txt, which is a business trade-off rather than a technical one.

Is technical SEO enough to rank? No. It removes obstacles rather than creating demand. It is a multiplier on content that deserves to rank, and a multiplier on nothing is nothing.