Technical SEO Work

Technical SEO covers the infrastructure that allows search engines to crawl, render, index, and serve your pages. It includes things like site speed, crawlability, canonical handling, structured data, mobile responsiveness, and rendering behavior. It matters because none of your content strategy or link building works if Google can’t access and process your pages correctly in the first place.

Google Search Console is the starting point. The Coverage report shows you which pages are indexed, which are excluded, and why. The Crawl Stats report shows how often Google visits and how much it downloads. For deeper analysis, server log files show exactly which URLs Googlebot requests, how often, and what response codes it gets. The gap between what you want indexed and what Google actually indexes is where most technical problems live.

Crawl budget is the number of pages Google will crawl on your site in a given period. For most sites under a few hundred pages, it’s not a real concern. Google will crawl everything. It becomes critical on large sites (1,000+ pages) where faceted navigation, parameter URLs, or infinite pagination can generate thousands of crawlable URLs that waste budget. If your important pages are taking weeks to get re-crawled after updates, crawl budget is probably the bottleneck.

A canonical tag tells Google which version of a page is the “official” one when multiple URLs serve the same or very similar content. This happens more than most people realize: HTTP vs HTTPS, www vs non-www, trailing slash variations, UTM parameters. Without proper canonicalization, Google might split ranking signals across duplicates instead of consolidating them. The canonical tag is a signal, not a directive. Google can and does override it if your internal links, sitemaps, and redirects disagree.

Google can render JavaScript, but it’s a two-phase process. First it crawls the initial HTML. Then it queues the page for rendering, which can take hours or days. If your content, links, or metadata only exist after JavaScript runs, there’s a delay before Google can see them, and a risk they won’t render correctly. The safest approach is server-side rendering or hybrid rendering where critical content is in the initial HTML response. Client-side rendering for interactivity is fine, but critical SEO content should never depend on it.

Before: complete URL mapping (old to new), redirect plan (301s, not 302s), baseline traffic and index data, backlink audit to prioritize redirects for pages with external links. After: validate every redirect works, monitor Search Console for crawl errors and index drops, check that no old URLs return 404s, compare indexed page counts weekly for at least 6 weeks. I wrote a more detailed framework for repeatable migration processes.

Core Web Vitals measure loading performance (LCP), interactivity (INP), and visual stability (CLS). They are a confirmed ranking signal, but a relatively light one compared to content relevance and links. Where they matter most is as a tiebreaker and as a user experience factor. A slow site loses visitors before your content ever gets a chance. The important thing is measuring against real user data (Chrome User Experience Report), not just lab tools like Lighthouse, because real-world performance on real devices is what Google uses.

Structured data (JSON-LD schema markup) gives search engines explicit information about what your content means, not just what it says. It can enable rich results in Google (FAQ dropdowns, product ratings, how-to steps) and helps AI search systems extract and attribute information more accurately. The key rule: structured data must match visible page content. Marking up content that users can’t see violates Google’s guidelines and will get you penalized.

A 301 is a permanent redirect. It tells search engines that the old URL has permanently moved and to transfer ranking signals to the new URL. A 302 is a temporary redirect, meaning the old URL might come back. Google handles them differently: 301s consolidate link equity to the new URL, while 302s keep the original URL in the index. For site migrations and URL changes, you almost always want 301s. I see 302s used accidentally more often than intentionally, and it’s one of the easiest things to catch in an audit.

I work in this order: indexation and duplication risks first (are the right pages indexed, are duplicates consolidated), then crawl and internal link structure (can Google find everything, is authority flowing correctly), then site architecture (does the hierarchy make sense), then metadata and template consistency, then performance, and finally enhancements like schema. The logic is simple: fix the things that prevent pages from appearing in search before optimizing the things that make them rank better. No point polishing a page Google can’t even find.