Technical SEO in one minute
Think of a library with excellent books, locked corridors and duplicate catalogue entries. The content exists, but the right version is difficult to locate. Technical SEO improves access and organisation. Begin with discovery and server responses, then examine rendering and indexing instructions before prioritising performance refinements. Passing these checks makes a page eligible to participate in search; it does not guarantee indexing or a high position.
Technical SEO follows the path from discovery to indexing
The introductory SEO guide places crawling and indexing within the wider search process. Here we examine the technical conditions each stage needs and why a failure in one stage requires a different response from a problem in the next.
Crawling. A crawler requests URLs and retrieves their resources. Discovery can happen through internal links, external links or a sitemap. A URL that exists in a spreadsheet is not necessarily easy to find on the website. Check server availability, crawl permissions and the routes leading to important pages. Fetching a page and deciding to index it are separate events.
Indexing. After retrieving and processing content, a search engine may store information about it in its index. Successful crawling does not guarantee inclusion. Quality, duplication and indexing instructions can affect the outcome. Use a specific reported reason as the starting point for diagnosis. “Not indexed” describes a state; it is not a complete explanation and does not automatically call for more words.
HTTP status and redirects. A 200 response normally indicates successful delivery; 301 and 308 communicate a permanent move. A missing page may correctly return 404 or 410. Server errors such as 5xx require a different investigation. Avoid a “not found” message with an unrelated success response. Redirect moved content to a relevant replacement, not every old URL to the homepage, and minimise unnecessary redirect chains.
robots.txt and noindex. robots.txt controls crawler access to specified resources. It is not a dependable instruction to keep a URL out of search results. A noindex directive addresses indexing, but the crawler must be able to retrieve the page or response to see it. Blocking crawling can therefore prevent discovery of a noindex change. Neither mechanism is a substitute for authentication when information must remain private.
JavaScript and rendering. A server may return complete HTML or deliver a shell that JavaScript fills in. Google can render JavaScript, but inaccessible resources, errors and content dependent on user actions create risks. Compare the initial response with the rendered page, including text, links and metadata. A screen that works after you sign in or click is not proof that a crawler receives the same main content.
Keep architecture, versions and indexing signals consistent
Architecture assigns roles and relationships to pages. A category groups products, a hub organises explanations and a detail page answers a focused question. URL folders are only one part of that structure. Short URLs can work with hierarchical navigation when links and breadcrumbs make the relationships clear. Do not let a template produce a new crawlable route for every insignificant variation without deciding what those routes are for.
Canonical URLs and duplicates. A canonical expresses a preference for the representative version of identical or closely similar content. It is a signal, not an absolute instruction. Align internal links, redirects and sitemap entries with the preferred URL. Do not point a canonical to unrelated content to conceal a problem. Ordinary duplication is not automatically a penalty, but can fragment processing and reporting. Investigate causes such as parameters, print views and multiple product paths.
XML sitemaps. A sitemap lists URLs you want search engines to know about. Prefer accessible, canonical pages intended for indexing. Remove persistent errors and use lastmod to reflect substantive updates. A sitemap does not replace navigation. It may have a different practical role on a small, well-linked website than on a large catalogue that publishes new pages frequently.
International versions. Give each language an accessible URL. Hreflang connects equivalent versions and should be reciprocal and consistent. A Dutch page normally has a canonical pointing to its own Dutch URL; do not canonicalise useful translations into one language. Language navigation should lead to the same topic. Hreflang neither translates text nor repairs an absent or unsuitable translation.
- Symptom
A fictional shop launches a useful category with products and clear guidance. Customers can open it, but Search Console reports a noindex instruction.
- Investigation
The instruction came from the staging template. The developer checks related templates and HTTP headers to establish the scope before changing the configuration.
- Correction and follow-up
Only the unintended noindex is removed. The page remains accessible, receives appropriate internal links and uses the intended URL in the sitemap. Inspection and monitoring follow, without promising immediate indexing.
Connect performance checks with an actionable technical plan
Core Web Vitals. LCP concerns the appearance of the largest visible content element, INP the responsiveness of interactions and CLS unexpected layout shifts. Examine real-user field data where available alongside laboratory tests. A heavy hero image, blocking scripts and missing image dimensions require different interventions. Good measurements support usability; they do not make an incomplete product list relevant to every query.
Structured data. Markup such as JSON-LD describes visible information in a structured form. Choose types and properties that fit the page. Article describes an article, not an invented review, while Product needs real product details. Validate both syntax and factual accuracy. Not every schema type produces a special Google result, and valid markup does not guarantee one. Entity SEO explains identity and relationships beyond the markup itself.
Technical SEO is not the same as programming. An SEO review may establish that indexable filter pages have no distinct purpose. A developer can then adjust routing or templates, while an editor improves the useful categories. The implementation follows an information decision. “The code is valid” and “the intended page can be found” are different checks, and both may be needed before closing an issue.
- Choose representative templates: home, service, category, product and language version.
- Check access, HTTP status, rendered main content and internal discovery routes.
- Compare canonical, noindex, robots.txt and sitemap signals for contradictions.
- Review filters, redirects, mobile interaction, structured data and performance.
- Prioritise blockers before minor refinements and record evidence, ownership and the post-change check.
Keep the connection with on-page SEO explicit. Reliable delivery gives a page the chance to answer a question; the content must still provide that answer. In the other direction, reorganising content may create technical decisions about redirects or language equivalents. Preserve a baseline and a change record. When a new problem appears, those records help identify what changed instead of reversing settings at random.