What Is Technical SEO? A Plain-English Guide for Business Owners

A situation I see a few times a year goes like this. A Navi Mumbai business launches a new website. It looks better than the old one, the owner is happy, and for six weeks enquiries from Google slowly dry up. Nobody touched the content. The cause is one setting the developer switched on during the build to hide the unfinished site from Google, and forgot to switch off at launch.

That is technical SEO: the plumbing that decides whether Google can reach, read and trust your pages. It matters more in India than people think, because Google is close to the whole market. Statcounter puts Google’s share of search in India at 96.63% in September 2026. If Google cannot read your site, almost nobody searching will find it. So the question this guide answers is simple: what does technical SEO cover for a small business, and which parts can you check yourself this week?

1. What technical SEO covers, and what it does not

SEO is usually split into three parts. Technical SEO is how your site is built and served. On-page SEO is what each page says and how it is structured. Off-page SEO is your reputation elsewhere: reviews, listings and links from other websites. All three matter, but technical problems can quietly cancel out the other two.

Think of your website as a shop. The products and the window display are the content. Technical SEO is whether the shutter opens, the lights work and the address on the board is right. A beautiful shop with a jammed shutter sells nothing.

It is worth saying what technical SEO is not. It will not make a thin page rank, and it will not fix a business that has no reviews. In my experience, the biggest gains come from removing a blocker, such as a stray noindex tag or a broken redirect, rather than from fine-tuning. Once nothing is blocking Google, extra technical work has diminishing returns for a small site.

2. How Google finds, reads and ranks a website

Google describes its process in three stages in its guide How Google Search works: crawling, indexing and serving results. Each stage has its own failure points, and knowing which stage failed tells you where to look.

Crawling

Google’s crawler visits pages and follows the links on them. If a page has no links pointing to it and is not in your sitemap, the crawler may never find it. If your server is slow or keeps returning errors, Google crawls less.

Indexing

After visiting a page, Google decides whether to store it in its index. Pages can be crawled and still left out, for example if they look like a copy of another page or carry a noindex instruction.

Ranking

When someone searches, Google picks pages from its index and orders them. Only indexed pages can rank. That is why technical problems come first: they decide whether a page is even in the race.

Source: stages from Google, How Google Search works. The failure examples are from my own audits.

3. Let Google in: robots.txt and noindex

Two settings control access. A file called robots.txt tells crawlers which parts of the site not to visit. A noindex tag tells Google not to list a page. Both are useful. Both can wipe out your traffic if set wrongly, which is what happened in the launch story above.

Many people, including some developers, mix up the two. Google’s robots.txt introduction says robots.txt is for managing crawler traffic and is not a way to keep a page out of Google. It warns that a blocked page’s URL can still appear in search results, and that a disallowed page “can still be indexed if linked to from other sites.” To keep a page out, Google says to use noindex or password-protect it.

The catch: Google can only see a noindex tag on a page it is allowed to crawl. If you block a page in robots.txt and also add noindex, Google never reads the noindex. We made exactly this mistake on our own site, which I describe in section 9.

4. One page, one address: redirects and canonicals

To Google, these four addresses can be four different pages, even though they show the same homepage:

Illustration. Pick www or non-www; either is fine as long as you pick one.

Google’s page on consolidating duplicate URLs lists the reasons to pick one address: to choose which URL people see in results, to combine signals such as links that point at different copies, and to avoid wasting crawl time on duplicates. It ranks the methods by strength. Redirects and the rel="canonical" tag are both strong signals. Listing a URL in your sitemap is a weak one.

Two honest notes. First, Google does not describe duplicates as a penalty. The same page says a site “will likely do just fine” without a canonical preference, because Google picks a version itself. Second, I still fix duplicates on every site I touch, because I would rather tell Google which address is right than let it guess. A redirect rule usually takes minutes.

On redirects, use the right type. Google’s HTTP status code documentation treats a 301 (permanent) as a strong signal that the new address should be used, and a 302 (temporary) as a weak one. For a page that has moved for good, use 301.

5. Sitemaps: useful, but not magic

An XML sitemap is a file listing the pages you want in Google. Most website builders and WordPress SEO plugins create one automatically. Every automated audit tool flags a missing sitemap as a serious error, which overstates it.

Google’s sitemap overview says you might not need one if your site is small, which it defines as “about 500 pages or fewer”, and that a sitemap “doesn’t guarantee that all the items in your sitemap will be crawled and indexed.” Submit one anyway, because it costs nothing and gives you useful error reports in Search Console. Just do not expect it to fix an indexing problem on its own.

The same goes for crawl budget, a phrase that appears in a lot of SEO sales pitches. Google’s crawl budget guide says it is written for sites with roughly a million or more unique pages, or 10,000 or more pages that change daily. If your site does not have a large number of pages that change rapidly, Google says you do not need to read it. That covers nearly every small business site in Mumbai.

6. Speed and Core Web Vitals

Google measures real-world loading with three numbers called Core Web Vitals. Each is judged at the 75th percentile of page loads, which means three out of four visits need to hit the target.

Source: targets from web.dev, Web Vitals; pass rates are global figures from the HTTP Archive Web Almanac 2024, Performance chapter. I could not find a reliable India-only figure, so none is given.

So more than half of mobile sites worldwide fail at least one of the three. If yours fails, you are in common company, and that is part of my point: speed is a tie-breaker more often than a deciding factor. Google’s page experience guidance says Core Web Vitals “are used by our ranking systems”, but also that there is no single page experience signal, and that Google “always seeks to show the most relevant content, even if the page experience is sub-par.”

Where speed clearly matters is with your visitors. A slow page on a mid-range phone over a patchy 4G connection loses people before it loads, whatever it does to rankings. The usual causes on small business sites are oversized images, too many plugins and cheap shared hosting.

See also: The fixes, in order of effort, are in how to speed up your website.

7. Mobile first, because your customers are

Statcounter estimates that 77.3% of web traffic in India in September 2026 came from mobile, against 22.1% from desktop. Google works the same way. Its mobile-first indexing guide says Google “uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.”

That has a practical consequence. If your mobile layout hides text, drops a section or cuts off a table to save space, Google may not count what is missing. Google’s advice is to keep the same content on mobile and desktop, and to use tabs or accordions rather than removing content. A responsive site, where one page adapts to the screen, avoids most of this by design.

8. Broken links, removed pages and server errors

Every page answers Google with a status code. Getting these right is unglamorous and it matters, especially after a redesign, when old addresses break in bulk.

Source: Google Search Central, How HTTP status codes and network errors affect Google Search.

One mistake I see often is the “soft 404”: a deleted page that shows a friendly “sorry, not here” message but still returns 200. Google sees a working page with almost nothing on it. When you remove a page, redirect it to the closest live page, or let it return a real 404 or 410.

9. Structured data: telling Google what you are

Structured data, also called schema markup, is a small block of code that states facts in a format Google reads easily: your business name, address, phone number, opening hours and services. Visitors do not see it.

Two rules from Google’s structured data guidelines are worth knowing. Google “does not guarantee that your structured data will show up in search results.” And you should not mark up content that is not visible to readers of the page. In practice, that means your schema should repeat what the page already says, and match your Google Business Profile exactly.

10. What we found when we audited our own website

In October 2026 we ran a full technical audit on infoways.in, the same kind we run for clients. Our site is fast and built carefully, and it still had real problems. None were visible to a normal visitor.

The whole site existed twice

Every page loaded on both infoways.in and www.infoways.in, with no redirect. Only a canonical tag stopped Google from treating them as two sites. Fix: one permanent redirect rule sending every www address to the main domain.

Over 3,700 internal links pointed at duplicate addresses

Our menus linked to addresses like /seo/index.html instead of the clean /seo/. Both loaded, so our own links sent Google to the duplicate while the sitemap listed the clean version. Fix: one change in the code that builds our links, plus a redirect from any /index.html address to the clean one.

Other projects showed up under our domain

Our hosting account stores several unrelated projects in the same folder, so they were reachable as infoways.in/project-name/. They were blocked in robots.txt, which, as section 3 explains, does not remove them from search. Fix: a server rule that sends a noindex signal for those folders, and removing them from robots.txt so Google can see that signal.

One stray character broke the mobile layout

A single extra semicolon in the stylesheet stopped a mobile rule from working, so a row of eight tiles squeezed into boxes 68 pixels wide on phones. Labels like “Manufacturing” were cut to “Manuf”. Nothing looked wrong on a laptop. Fix: delete one character.

Spam pages from an old hack were still in Google

An earlier malware attack had created thousands of fake product pages. They were deleted months earlier, yet Search Console still showed 27 of them appearing in search. Server rules now return “410 Gone” for those addresses. Public crawl records showed that for part of August they returned 404 instead, which suggests the rule was lost during a deployment. Server rules can quietly disappear, so re-check them after changes.

One issue was still open when we wrote this: our hosting provider’s CDN returned “too many requests” (429) to OpenAI’s crawler on some pages. That is a hosting setting rather than our code, so we raised it with the provider.

None of these problems were visible to a normal visitor. All of them affected how search engines saw the site. That is the nature of technical SEO.

11. Can you fix it yourself, or do you need a developer?

It depends on the problem and on how your site is built. Wix and Shopify handle many technical settings for you. WordPress gives you more control through settings and plugins. Custom-built sites usually need a developer for anything beyond content.

Source: my own experience across client sites; effort assumes one small business site.

If you are not sure what a setting does, do not change it on a live site. A wrong robots.txt or redirect rule can remove your site from Google faster than it took to build up.

Where this advice breaks down

This guide is written for small business sites in one language with a few hundred pages at most. It does not cover large ecommerce catalogues with filters that create thousands of URLs, multi-language sites that need hreflang, or sites built as JavaScript apps where Google has to render the page to see content. Those need a proper crawl with paid tools and someone experienced.

It also has a ceiling. A technically perfect site with thin content and no reviews will still lose to a messy site that answers the searcher better. Google says as much in its page experience guidance. Fix the blockers, then spend your time on content, your Google Business Profile and reviews. And be wary of anyone who sells a 300-item technical report as the answer to falling enquiries; most of those items will not move anything.

Finally, timing. Google recrawls pages on its own schedule, so fixes take weeks to show, not days. If someone promises results from technical changes by next Monday, ask how.

See also: For the wider audit, including content and local signals, use our step-by-step SEO audit guide. If pages are missing from Google entirely, start with why a website is not showing on Google.

Your 10-step technical SEO check

The business owner with the forgotten “hide from Google” setting got their enquiries back about a month after one tick box was changed. Most technical SEO is like that: small, invisible, and the difference between being found and not.