Google crawled our own site last month and choked on something we didn’t even know was broken. A WordPress widget looping through post cards without resetting the global post object, quietly corrupting the schema graph Yoast was trying to build. Nobody noticed until the structured data started throwing errors in Search Console. That’s technical SEO in a sentence: the stuff nobody sees until it’s already gone wrong.

What Is Technical SEO?

Technical SEO covers whether Google can find, understand, and trust your site. Not the words on the page, everything underneath them. Most people only clock it exists once something’s already broken. A page drops out of search overnight. A schema error turns up in Search Console. Load times start crawling and nobody’s touched the theme in months.

Why it gets overlooked

A few things technical SEO covers:

• Whether Google’s crawlers can physically reach your pages
• Whether those pages get indexed once found
• How fast your pages load and how stable they feel while loading
• Whether structured data correctly describes what’s on the page
• Whether duplicate or templated content is confusing search engines about which version to rank

Crawling, Indexing and Rendering Are Three Different Problems

It helps to split technical SEO into three distinct stages, because a fix for one won’t touch the others.

The three stages

• Crawling – whether Googlebot can physically reach a page at all
• Indexing – whether Google decides that page is worth storing and serving in search results
• Rendering – whether Google can execute the page’s JavaScript and see the content the way a user does

A page can pass one of these stages, all three, or none, and that’s where it gets confusing for people expecting a straight pass/fail. We’ve had sites where every single page returns a 200 and crawls without issue, yet half of them sit in “Discovered, currently not indexed” in Search Console. Google found them. Google rendered them. Google just didn’t think they were worth keeping. Calling that a crawl problem misses what’s actually happening.

HTTP Status Codes Are the First Conversation Between Your Server and Google

Every request a crawler makes gets a response code, and reading those codes properly saves hours of guessing.

The codes worth knowing

• 200 (OK) – what you want on any page meant to be indexed
• 301 (Moved Permanently) – passes ranking signals to a new URL, use it when the old one is gone for good
• 302 (Found) / 307 (Temporary Redirect) – tells Google the move isn’t permanent, so don’t reach for these out of habit when the old URL is never coming back
• 404 (Not Found) – fine when a page is genuinely gone and nothing should replace it
• 410 (Gone) – the more decisive version of 404, useful when you want Google to drop the URL faster
• 500 (Internal Server Error) – at scale, a hosting or plugin conflict rather than an SEO issue, though it becomes one fast if left unresolved

Watch for redirect chains

Sorting a Screaming Frog crawl by status code tends to surface where these pile up fastest. Redirect chains are the usual suspect, one URL hopping through two or three others before it finally lands somewhere. We see this constantly on older WordPress sites that have been redesigned two or three times over the years. Collapsing the chain down to a single 301 straight to the final destination is worth doing every time one turns up.

XML Sitemaps and Robots.txt Aren’t the Same Job

A sitemap is basically Google’s map of what exists on your site and what you think matters most. Robots.txt does something almost opposite: it tells Google which bits not to bother with. People mix the two up more than you’d expect, and it’s caused some genuinely frustrating problems for clients.

Here’s the trap. Disallowing a URL in robots.txt doesn’t pull it out of the index, it just stops Google from crawling it again. So an old page you noindexed years ago can keep resurfacing in search results, because Google’s now blocked from getting back in to even see that noindex tag is there.

Where each tool actually belongs

• If a page genuinely needs to stay out of the index, block it with a noindex meta tag or X-Robots-Tag header, not robots.txt
• Save robots.txt for genuinely low-value crawl targets: internal search result pages, filtered archive combinations, staging paths
• Check your sitemap against Search Console’s coverage report periodically, since plugin conflicts can silently exclude entire post types without any error message appearing

Schema Markup Fails Silently, Which Is the Whole Problem With It

Structured data tells search engines what a page actually is, using JSON-LD embedded in the page’s head. Article, LocalBusiness, FAQPage, Product, whatever fits. Done properly it earns rich results. Done badly, or broken silently, it can undercut everything else on the page without a single visible symptom on the front end.

A real example

That’s exactly what happened with our own NewsArticle schema. A Post Cards widget was running a WordPress loop through recent posts without calling wp_reset_postdata() afterwards, which left the global $post object pointing at the wrong content by the time Yoast generated its schema graph downstream. Every field looked plausible. The headline was there. The dates were there. They just belonged to the wrong article half the time.

The only way to catch this class of bug is checking the actual rendered JSON-LD periodically, either through Search Console’s structured data reports or by pasting the live page into Google’s Rich Results Test. A schema block validating in isolation tells you nothing about whether the data feeding into it is correct at the point of generation.

Core Web Vitals: The Thresholds That Actually Matter

Core Web Vitals are a confirmed ranking factor. Small technical improvements here can shift competitive rankings even when nothing else on the page changes.

LCP covers loading and needs to land under 2.5 seconds. INP, which replaced FID as the responsiveness metric, wants to sit under 200 milliseconds. CLS is the odd one out, measuring visual jumpiness rather than speed, and should stay below 0.1.

A video background in a homepage hero is a common offender against LCP, particularly on mobile where a meaningful chunk of Melbourne small business search traffic still lands first. A static image standing in for mobile users handles most of the LCP damage without touching how the page looks on desktop at all. Uncompressed, oversized images cause the other half of the trouble we usually find, and lazy loading anything sitting below the fold claws back real milliseconds with zero visual cost.

Nobody notices a fast site. Everybody notices a slow one. That asymmetry is worth remembering next time Core Web Vitals feels like a box-ticking exercise.

Canonicalisation Solves a Technical Problem, Not a Content Problem

A canonical tag tells Google which version of near-identical content is the one that should rank. It’s the right tool for URL parameter duplication, print versions, or the same product appearing under two category paths.

Where canonicals don’t help

It is the wrong tool for what we actually see most often on niche service pages: content that’s templated rather than genuinely duplicated at the URL level. Service pages built from the same skeleton, same FAQ section, same paragraph with a find-and-replace on the industry name, aren’t a canonicalisation problem. Really they’re just separate URLs carrying separate content, content that happens to read as near-identical to both a user and to Google.

Slapping a canonical on it doesn’t help. There’s nothing to consolidate, because nothing’s actually a duplicate in the technical sense. What fixes it is writing copy that’s genuinely different for each vertical, which sounds like a content job because it is one, dressed up as though it were a technical fix.

Internal Linking Is the Highest-Leverage Task Nobody Schedules

Google reads internal link patterns as a signal of what actually matters on a site. A page with strong external backlinks but almost no internal links pointing to it sends a confusing signal, important enough for outsiders to reference, apparently not important enough for the site’s own structure to reinforce.

How pillar structures help

Pillar and cluster structures exist to fix this deliberately:

• A broad page like this one sits at the top of a topic
• It links down into narrower supporting posts
• Those posts link back up to reinforce the hierarchy

It’s also the task that gets skipped constantly, because writing new content is visible progress and going back through old posts to add contextual links isn’t. A blog with seventy posts and almost no cross-linking between them is leaving authority sitting on the table it already earned.

Mobile-First Indexing Still Trips People Up

Google has indexed the mobile version of most sites for years now, not desktop. We still come across sites hiding content on mobile that’s fully present on desktop. Usually it’s meant as a cleaner mobile experience. Google doesn’t see it that way. If it’s not in the rendered mobile version, as far as indexing is concerned it doesn’t exist.

Fonts render differently. Accordions sometimes collapse content Google never bothers expanding. Lazy-loaded images occasionally don’t load in time for the crawler to catch them. None of this shows up unless you actually pull up the rendered mobile page and look, rather than trusting that a responsive theme has it covered.

WordPress Adds Its Own Layer of Technical Risk

WordPress runs a huge share of small business websites in Australia, ours included, and it comes with recurring technical issues that aren’t really about SEO at all until they are.

Common WordPress-specific risks

• Plugin conflicts that break rendering or schema output without warning
• Themes holding onto deprecated functions after updates
• Security vulnerabilities in widely-used plugins that can tank trust signals overnight if left unpatched
• Direct functions.php edits, where a single typo can take the whole site down

A typo in functions.php can white-screen the entire site in one keystroke. A snippet manager plugin sidesteps that risk entirely, which beats finding out the hard way on a Saturday.

Technical SEO rarely gets noticed when it’s done well. Mostly it just stops causing problems.