Technical SEO basics for site owners

Technical SEO basics come down to one idea: Google has to be able to find your pages, read them, understand which version to show and load them quickly for a visitor on a phone. If any of those steps fails, the best content in your industry won't rank. The good news for a small business is that the technical side is usually a short list of settings that are either right or wrong, not an endless project.

You don't need to become a developer. You need to know enough to spot problems, ask the right questions and tell whether your web person fixed them. Here are the nine concepts that matter most, in plain language.

1. Crawling: can Google find your pages?

Google discovers pages by following links, from other sites and from page to page within yours, and from your XML sitemap. A page that nothing links to (an "orphan") may never be found. A page buried five clicks deep gets visited less often.

What to check: every important page is reachable from the menu or from another relevant page within two or three clicks, and your sitemap is submitted in Search Console.

2. robots.txt and noindex: two different stop signs

These get confused all the time.

• robots.txt tells Google which areas not to crawl. It's a "don't go in" sign.
• noindex is a tag on a page that says "you can read this, but don't show it in results".

A common mistake is blocking a page in robots.txt while also adding noindex: Google can't crawl the page, so it never sees the noindex, and the page can linger in results. Another is a developer's "block everything" left on after launch.

What to check: open yourdomain.ca/robots.txt and make sure it doesn't say Disallow: /. Use URL Inspection in Search Console on your key pages.

3. Indexing: is Google keeping your pages?

Crawled doesn't mean indexed. Google may read a page and decide not to keep it, often because it's thin, duplicated or low value. The Pages report in Search Console lists every reason, like "Crawled, currently not indexed" or "Duplicate without user-selected canonical".

What to check: the number of indexed pages roughly matches the number of real pages you have. Big gaps either way mean something is off.

4. Canonicals and duplicates

The same content can often load under several addresses: with and without www, with tracking parameters, with a trailing slash or without. A canonical tag tells Google which version is the main one. Without it, Google picks, and sometimes picks badly.

What to check: only one version of your homepage loads; the others redirect to it. Each page has a canonical pointing to itself (or to the main version).

5. Redirects and broken pages

When a page moves, a 301 redirect sends visitors and Google to the new address and carries most of the old page's value with it. A missing redirect leaves a 404 error, and the ranking the old page had is gradually lost.

What to check: the Pages report for "Not found (404)" on pages that used to matter, and that old URLs go to the closest matching new page rather than all to the homepage. This becomes critical during a redesign; see moving a website without losing Google traffic.

6. Mobile-first

Google primarily uses the mobile version of your site for indexing and ranking. If the mobile version hides content, cuts text or makes buttons hard to tap, that's what Google judges you on.

What to check: open every key page on your phone. Is all the important content there? Is the phone number tappable? Does anything overflow the screen?

7. Speed and Core Web Vitals

Google measures real user experience through Core Web Vitals: how fast the main content appears (LCP), how quickly the page responds to taps (INP) and whether things jump around while loading (CLS). These are one ranking signal among many, but a slow page loses visitors long before it loses rankings.

What to check: the Core Web Vitals report in Search Console, which uses data from real Chrome users. For a deeper dive, see slow website fixes.

Common causes on small business sites: oversized images, too many plugins or third-party scripts, cheap shared hosting, heavy page builders and sliders. Some of these are configuration; some are baked into how the site was built.

8. HTTPS and security

Every page should load over HTTPS with a valid certificate. Browsers warn visitors about insecure pages, and a hacked site can get flagged in search results.

What to check: the padlock in the browser on every page type, and the Security issues report in Search Console.

9. Structured data

Structured data (usually JSON-LD code in the page) labels information for search engines: this is a business, here are its hours, this is its address, this page is a product with a price. It can make you eligible for richer results and helps Google understand your business. My guide to schema markup for local businesses covers what to add.

A short glossary for talking to your developer

Fix or rebuild?

Most technical issues on a reasonably built site take hours, not weeks: remove a noindex, add redirects, compress images, submit a sitemap. But if the site sits on a heavy builder with dozens of plugins, a theme nobody updates and no access to the code, every fix becomes a workaround. That's often the point where a rebuild is cheaper over two years than patching. I build sites hand-coded or on a custom CMS, so the technical basics are handled from the first day rather than added later.

If your site is sound and you want someone to keep the technical side in order month to month, that's part of my technical SEO work.