What is technical SEO and why should a business owner care about it?

Most business owners hear "SEO" and picture blog posts, keyword research, or social media. But before Google can rank your content, it has to find it, read it, and trust it. That’s the job of technical SEO. It’s the plumbing behind your website — invisible when it works, catastrophic when it doesn’t.

You don’t need to know how to code. You need to know what to ask your developer, what to check in your own dashboard, and when something is broken enough to cost you money. This guide covers the five technical SEO areas that actually move the needle for a typical small business site in Calgary. Skip the rest — server-side rendering frameworks, Core Web Vitals optimization beyond basic image compression, and hreflang tags are overkill unless you’re running a multinational e-commerce platform.

Is your sitemap actually helping Google find your pages?

A sitemap is a file (usually XML) that lists all the important pages on your site. Think of it as a table of contents handed directly to Google. Without one, Google relies on following links from your homepage to discover pages — which works fine for a 10-page site but falls apart once you have 50+ pages, blog archives, or service pages buried three clicks deep.

Why it matters: If Google can’t find a page, it can’t rank it. A new service page you launched last week might take weeks to appear in search results if it’s not linked prominently and not in your sitemap.

How to check yours:

  • Go to Google Search Console → Sitemaps. If you see a green checkmark, you’re in good shape. If it says "Couldn’t fetch" or shows zero submitted pages, you have a problem.
  • Try visiting yourdomain.com/sitemap.xml in your browser. If you get a 404 or an error, your sitemap isn’t accessible.

What to tell your developer: "Make sure we have an XML sitemap that auto-updates whenever we add or remove a page. Submit it to Google Search Console and Bing Webmaster Tools. Exclude any pages we’ve marked as noindex."

Common mistake: Some WordPress plugins generate sitemaps but don’t exclude draft pages, staging environments, or internal search result pages. Those junk URLs waste crawl budget and can dilute your site’s quality signals.

Does your robots.txt file accidentally block Google from important pages?

The robots.txt file sits at yourdomain.com/robots.txt and tells search engine crawlers which parts of your site they’re allowed to visit. It’s not a security tool — it’s a polite request. But if misconfigured, it can silently block Google from your entire site or from critical sections like your service pages.

Why it matters: If robots.txt blocks your homepage or service pages, Google will deindex them. You won’t see a warning in Search Console because Google interprets blocked pages as "we can’t access this, so we won’t rank it." Sites have lost 80%+ of organic traffic from a single misplaced line.

How to check yours:

  1. Visit yourdomain.com/robots.txt in your browser.
  2. Look for lines like Disallow: / — that blocks everything. Red flag.
  3. Check for blocks on paths like /wp-admin/ (fine), but not /services/ or /blog/ (not fine).

What to tell your developer: "Review our robots.txt to ensure we’re not blocking any pages we want indexed. The only Disallow rules should be for admin panels, internal search results, and staging environments. Everything else should be allowed."

Edge case: If you use a staging site (like staging.yourdomain.com), make sure that domain has a robots.txt that blocks all crawlers. The production site should not.

Is your site running on HTTPS everywhere, with no mixed content warnings?

HTTPS means your site uses an SSL certificate to encrypt data between the visitor’s browser and your server. Google has used HTTPS as a lightweight ranking signal since 2014, but the bigger issue is trust. Chrome displays a "Not Secure" warning on HTTP pages, which kills conversions for any business handling contact forms, quotes, or bookings.

Why it matters: Beyond the minor ranking factor, browsers actively penalize HTTP sites in the address bar. For local service businesses, that red "Not Secure" label next to your URL in search results or when someone shares your link is a credibility killer.

How to check yours:

  • Visit your homepage. Does the address bar show a padlock icon? Click it — it should say "Connection is secure."
  • Check your internal pages. Sometimes the homepage is HTTPS but a blog post or service page still loads resources (images, scripts) over HTTP. This is called "mixed content."
  • Use the Chrome DevTools console (press F12, go to the Console tab). Look for "Mixed Content" warnings.

What to tell your developer: "Ensure every page uses HTTPS. Fix any mixed content issues by updating hardcoded HTTP URLs in our templates, database, and CSS files. Set up a 301 redirect from HTTP to HTTPS at the server level so visitors always land on the secure version."

Common mistake: Some developers install an SSL certificate but forget to redirect HTTP to HTTPS. Both versions of every page load, creating duplicate content. Google sees http://yourdomain.com/services and https://yourdomain.com/services as two separate pages.

Are your redirects clean, or are you trapping crawlers in redirect chains?

A redirect tells a browser and search engine: "This page moved permanently — go here instead." You need them when you change a URL, remove a page, or consolidate content. But poorly implemented redirects create chains (A → B → C → D) or loops (A → B → A), which waste crawl budget and can prevent pages from being indexed.

Why it matters: Redirect chains add latency. Each hop means another HTTP request. If your top service page redirects through three intermediate URLs, Google may deprioritize crawling it. Worse, a redirect loop causes an infinite cycle — the crawler gives up and the page never gets indexed.

How to check yours:

  • Use a tool like the Redirect Chain Detector to scan your site for chains longer than one hop.
  • Check for 301s (permanent) vs. 302s (temporary). Use 301 for permanent moves. 302s tell Google "this might change back," so it keeps crawling the old URL.
  • Look for redirect loops. If visiting a URL bounces you back to the same URL, you have a loop.

What to tell your developer: "Audit our redirects. Every redirect should be a single 301 hop to the final destination. No chains, no loops, no 302s for permanent changes. Also, make sure we’re not redirecting 404 pages to the homepage — that’s called a soft 404 and confuses Google."

What most guides don’t tell you: When you migrate from HTTP to HTTPS and change URLs (e.g., removing .html extensions), you need to combine those redirects into one clean 301. A two-step redirect (HTTP → HTTPS → new URL) is technically fine but adds an extra hop. Best practice: configure your server to handle both in a single rule.

What are crawl errors, and how do you fix the ones that actually matter?

Crawl errors are URLs Google tried to visit but couldn’t. Search Console reports them under "Indexing" → "Pages." You’ll see categories like "404 Not Found," "Server Error (5xx)," "Redirect Error," and "Excluded by robots.txt."

Why it matters: Not all crawl errors are equal. A handful of 404s from old blog posts you deleted years ago? Ignore them. A pattern of 5xx server errors on your top service pages? That’s a crisis — Google stops crawling and may deindex those pages.

How to check yours:

  1. Open Google Search Console → Indexing → Pages.
  2. Look at the "Reason" column. Focus on: Server error (5xx), Redirect error, and Crawled – currently not indexed (if it’s a page you want indexed).
  3. Filter by URL. If the errors are on your homepage, main service pages, or contact page, escalate immediately.

What to tell your developer: "Check Search Console for 5xx errors on our primary pages. If we have them, investigate server logs — it could be a plugin conflict, PHP timeout, or hosting issue. For 404s, either restore the page, redirect it to a relevant replacement, or leave it as a true 404 if the content is genuinely gone. Do not redirect 404s to the homepage."

Honest caveat: "Crawled – currently not indexed" is the most common non-error in Search Console and usually means Google found your page but decided it wasn’t valuable enough to rank. That’s a content problem, not a technical one. Don’t waste your developer’s time on it.

What should you prioritize first?

If you’re overwhelmed, start here:

  1. HTTPS and mixed content — affects trust and conversions immediately.
  2. Robots.txt misconfiguration — silent killer, easy to check, devastating if wrong.
  3. Sitemap submission — five-minute fix, ensures Google finds new pages quickly.
  4. Redirect audit — matters if you’ve recently redesigned or restructured your site.
  5. Crawl errors — review quarterly, not daily.

These five areas cover about 90% of the technical SEO issues that actually impact small business sites. The other 10% — structured data, Core Web Vitals, canonical tags — matter too, but they’re secondary to making sure Google can access your site in the first place.

At Eikeland SEO, we handle the technical layer for Calgary businesses so owners can focus on running their company instead of deciphering server logs. If you want a professional to audit your site’s crawlability, indexing, and redirect health, get in touch and we’ll tell you exactly what’s broken and what’s not worth fixing.