Technical SEO Checklist: What Actually Matters and Why
September 24, 2026
Technical SEO checklists tend to list what to do without explaining why, which makes it hard to know which items actually matter for your specific site versus which are generic best-practice noise. This walks through the core technical SEO fundamentals — crawlability, indexation and structured data — with the reasoning behind each one, so you can prioritize based on what's actually likely to move the needle.
What does robots.txt actually control, and what does it not control?
robots.txt tells well-behaved crawlers which paths they're allowed or disallowed to request — it's a crawling directive, not an indexing one. A page disallowed in robots.txt can still appear in search results (typically with no description, since the crawler never fetched its content) if other pages link to it, because robots.txt prevents the crawl but doesn't prevent the URL from being known and listed. To actually keep a page out of search results, you need a noindex meta tag or header on the page itself, which requires the crawler to be able to fetch it — the two mechanisms solve different problems and are often confused for each other.
Why does an XML sitemap matter if crawlers can just follow links?
Crawlers do discover pages by following links, but a sitemap gives them a direct, complete manifest instead of relying entirely on internal linking to surface every URL — genuinely useful for large sites, pages with few internal links pointing to them, or sites that publish new content faster than organic crawling would otherwise discover it. A sitemap also communicates lastmod dates, which can help a crawler prioritize re-crawling pages that have actually changed rather than re-fetching unchanged pages on the same schedule. It's a hint and an efficiency tool, not a guarantee of indexing — a URL in a sitemap isn't automatically indexed if the page's content or other signals don't merit it.
What problem does a canonical tag actually solve?
Canonical tags tell search engines which URL is the 'real' version when the same or substantially similar content is reachable through multiple URLs — common with tracking parameters, printer-friendly versions, paginated content, or (in multilingual sites) a translated page that's mostly untranslated boilerplate around the same core content. Without a canonical tag, a search engine has to guess which version to index and may split ranking signals across duplicates or pick a version you didn't intend. It's a consolidation signal, not a redirect — visitors still reach the URL they requested, but ranking credit is directed toward the canonical target.
When does noindex actually make sense to use deliberately?
Noindex is the right tool for pages that are genuinely not meant to compete for search visibility: internal search results pages, personal account/dashboard pages, thin duplicate-intent pages that exist for UX reasons but add no unique value, or content in languages/regions you haven't actually translated and don't want indexed as a near-duplicate of another language's page. A common mistake is either noindexing too aggressively (hiding pages that would actually rank and drive traffic) or not noindexing enough (letting thin or duplicate pages dilute a site's overall content-quality signal) — the right threshold depends on whether the page offers genuinely distinct value to a searcher.
Why does structured data (schema markup) matter if it's invisible to visitors?
Structured data doesn't change what a human sees on the page — it's a machine-readable annotation layer that tells search engines explicitly what a piece of content is (a product, an article, a FAQ, a recipe, a local business) rather than making them infer it from unstructured text. That explicit labeling is what unlocks rich results — star ratings, FAQ dropdowns, product pricing snippets — directly in search results, which can meaningfully improve click-through rate even without a ranking position change, since a richer-looking result stands out against plain blue links.
How should you actually prioritize technical SEO work on a real site?
Start by confirming the basics aren't broken — pages you want indexed are actually crawlable and not accidentally noindexed, the sitemap is current and submitted, canonical tags point where intended — before moving to more advanced structured-data work. A site with a fundamental crawlability or indexation problem gets little benefit from adding rich schema markup to pages Google can't reach in the first place; fix the foundation, then layer in refinements like structured data and canonical consolidation once the basics are confirmed working.