Module 5: Technical SEO
Technical SEO is the plumbing underneath everything else: whether search engines can crawl the site, get the right pages into the index, and serve them fast enough that visitors stay. You don't need to be a developer to do this work well. You need to diagnose problems accurately, rank them by business impact, and hand developers fixes they can actually act on. This module covers the health audit, speed in plain terms, site architecture, and the highest-stakes job in the field — migrations.
The site health audit: find what's broken, rank it by impact
Every technical engagement starts the same way: crawl the site yourself and compare what you find against what Google reports. A crawler (the free tier of a tool like Screaming Frog covers small sites) walks every reachable URL and shows you status codes, titles, and link structure. Search Console's page indexing report shows the other half: what Google chose to index, and what it left out and why. The gap between "pages that exist" and "pages Google can find and index" is where audits live.
The findings sort into a few recurring buckets. Crawl errors: pages returning 404s that other pages still link to, server errors, and redirect chains that hop three or four times before landing — each hop wastes crawl effort and leaks signal. Index bloat: hundreds of thin tag pages, search-results pages, or parameterized URLs sitting in the index, diluting the site's average quality and eating the crawl budget a big catalog needs for real products. Duplicates: the same content reachable at multiple addresses — www and non-www, http and https, with and without trailing slashes — splitting one page's signal across several URLs. Broken internal links: links pointing at dead pages, quietly draining value and frustrating every visitor who clicks one.
The audit's real product isn't the list — it's the order. Rank findings by impact on revenue, not by how alarming they look. A money page accidentally blocked from indexing outranks forty duplicate title tags. A redirect chain on the homepage outranks one on a 2016 blog post. Cosmetic issues go at the bottom, plainly labeled as cosmetic, so a developer's limited hours go where the money is.
Write each finding so a developer can act without a meeting: the issue, how many URLs it affects, three example URLs, and the specific fix you want. "Site has duplicate content issues" gets ignored for a quarter. "312 product URLs are indexed twice, with and without the trailing slash — examples attached; please enforce one version with redirects and matching canonical tags" gets fixed this sprint. That precision is a large part of what clients are paying for.
Your audit of a 2,000-page store finds three things: the main category page that drives most sales is blocked from indexing by a leftover setting, 40 product pages have duplicate titles, and 300 thin tag pages are sitting in the index. What do you fix first?
Speed and Core Web Vitals, in plain terms
Core Web Vitals are Google's three measurements of whether a page feels fast and stable to a real visitor. You don't need the engineering vocabulary — you need to know what each one feels like from the user's chair, what usually causes it, and what to ask for when it's failing.
Largest Contentful Paint (LCP) is how long the main content — usually the hero image or headline block — takes to appear. Over about 2.5 seconds feels slow. The usual cause isn't exotic: a giant uncompressed hero photo is the single most common offender on small-business sites, followed by slow hosting and render-blocking scripts. Interaction to Next Paint (INP) is how quickly the page responds when someone taps or clicks. Heavy JavaScript, stacked third-party tags, and bloated page builders make pages feel sticky and unresponsive. Cumulative Layout Shift (CLS) is whether things jump around as the page loads — the button you were about to tap sliding down because an image or ad loaded late without reserved space. It's the most fixable of the three: give images and embeds set dimensions and the jumping mostly stops.
The fix list is boring, and that's good news. Compress images and serve modern formats. Delete plugins and tracking tags nobody uses anymore. Turn on caching. Move off the cheapest hosting tier if the server itself is the bottleneck. What you can safely ignore: chasing a perfect 100 score (the difference between 92 and 100 wins nobody any rankings), and optimizing pages that get no traffic while the homepage wheezes.
Set expectations with clients in plain language: speed is a tiebreaker and a conversion factor, not a cheat code. A fast site with weak content still loses; a strong page that's painfully slow bleeds visitors before it can persuade them. Measure with real-user field data from Search Console alongside lab tests from PageSpeed Insights, and re-measure after each fix so you can report what actually changed — "LCP on the top five landing pages went from 5.8 seconds to 2.1" is a sentence clients understand and renew over.
A client's homepage has an LCP of 5.8 seconds. The culprit is a huge uncompressed hero photo. Their developer proposes rebuilding the entire site on a new framework to fix it. What's your call?
Architecture and URL discipline: flat, clear, stable
Site architecture is the map of how pages relate: what lives under what, and how many clicks it takes to get there. Search engines read depth as a proxy for importance — and honestly, so do visitors. A service page buried six clicks deep under nested categories is telling everyone, including Google, that it doesn't matter much. The working rule: every important page should be reachable within about three clicks of the homepage, through navigation and links a human would actually follow.
Build the hierarchy so it mirrors how the business thinks about itself. A roofer's site wants /services/roof-repair/ and /services/roof-replacement/ sitting under a services hub — not a scatter of orphaned pages, and not /page?id=812. Categories should be real groupings a customer would recognize, each with a hub page worth linking to. Breadcrumbs on every page reinforce the structure and give both visitors and crawlers a clean path back up.
URLs are the addresses of that structure, and they follow their own discipline: short, readable, and honest about what's on the page. Lowercase, words separated by hyphens, the page's topic in plain language. /services/roof-repair/ will still make sense in five years. /services/best-cheapest-top-rated-roof-repair-dallas-tx/ is keyword stuffing wearing a URL costume, and /promo-2023-final-v2/ is a mess waiting to happen.
Above all: stability. A URL accumulates value over time — backlinks point at it, bookmarks hold it, Google's history lives there. Changing a URL without a redirect is throwing that accumulation away, which is why the most common architecture disaster isn't a bad structure, it's a tidy one: a redesign "cleans up" every address on the site and nobody maps the old ones to the new. If a URL must change, the 301 redirect is not optional paperwork; it is the move itself. Treat every existing URL as an asset with a balance, and you'll never talk a client into burning their own equity for tidiness.
A redesign moves /services/roof-repair/ to /what-we-do/roofing-services/. No redirects are set up. Two weeks later, organic traffic is down 40%. What most likely happened?
Migrations without disaster: redirect maps and monitoring
A migration is any change big enough to move a site's addresses or foundations: a new domain, a new platform, a major restructure. It's the premium end of technical SEO — specialists in site migrations sit at the top of the freelance market, reaching $350 an hour — because the downside is so asymmetric. Done well, a migration is a non-event. Done casually, it can erase years of rankings in a weekend, and the recovery is measured in months.
The work starts weeks before launch with a complete inventory: crawl the current site and export every URL, with its traffic and backlinks if you can get them. Then build the redirect map — a spreadsheet pairing every old URL with its closest equivalent on the new site, one to one. Not "everything redirects to the homepage" (Google treats that as a soft 404, and visitors treat it as a betrayal), but page to genuinely matching page. Pages with no equivalent get a deliberate decision: the nearest relevant destination, or an honest 404.
Test on staging before a single visitor sees it: crawl the test site, click through the redirect map's top hundred entries by hand, confirm the new site isn't accidentally blocked from indexing — the staging "keep search engines out" switch left on after launch is a classic, silent catastrophe. On launch day, work from a written checklist: redirects live, sitemap updated and submitted, robots file correct, analytics firing, and for a domain change, the change-of-address tool in Search Console.
Then monitor like it matters, because for four to eight weeks it does. Watch Search Console coverage and top-page traffic daily at first, then weekly; crawl the new site repeatedly to catch redirect gaps and new errors while they're cheap to fix. And two rules that protect every client: never schedule a migration in peak season, when a traffic dip costs the most, and never stack a migration on top of a full redesign if you can avoid it — when everything changes at once, nothing can be diagnosed. One variable at a time is how migrations stay boring, and boring is the goal.
A client wants to switch to a new domain AND launch a complete redesign in the same week — which happens to be their busiest sales month of the year. What's your advice?
What you can now do
- Run a site health audit with a crawler and Search Console's indexing report, then rank every finding by business impact, not by list order.
- Explain each Core Web Vital in plain terms — what it feels like from the visitor's chair, what usually causes it, and what to ask a developer for.
- Build a redirect map and a monitoring plan that carries a site through a migration without erasing years of rankings.