Technical SEO: make every search signal observable

Technical SEO is not a bag of crawler warnings. It is the control layer between a useful document and the systems that must discover, request, interpret, select, serve, and measure it.

That distinction matters. “The page does not rank” can mean the URL was never discovered, the server failed, the rendered document lost its main content, another canonical was selected, the page did not match the query, or the result earned impressions but no qualified action. One symptom, six different investigations.

This guide turns that ambiguity into an observable system. Each stage has evidence, a failure condition, and a next test.

The first control ring is now documented as three separate protocols: canonical signal alignment, robots.txt versus noindex, and XML sitemap inventory design. The downloadable Technical SEO Field Kit turns the protocols into 35 versioned audit checks with evidence and pass conditions.

Start with eligibility, not crawler scores

Google Search Essentials gives a useful minimum: Googlebot must not be blocked, the page needs a successful HTTP response, and the page must contain indexable content. Those conditions make a page eligible for consideration. They do not make it the best answer.

A crawler score compresses hundreds of checks into one number. That is convenient for reporting and poor for diagnosis. A score of 92 cannot tell a developer whether the commercial category template returns a soft 404, whether the canonical points to a parameter-free parent, or whether the primary copy appears only after a failed API request.

Replace the single score with a short evidence chain:

1. What URL should exist?
2. How is it discovered?
3. What does the server return?
4. What document exists before and after rendering?
5. Which canonical is selected?
6. Is the page indexed and served for the intended queries?
7. Does the visit create a useful outcome?

The first broken answer sets the work order.

Build a crawlable URL and link architecture

A stable URL represents a durable resource. Internal links tell crawlers and humans which resources exist, how they relate, and which route is the preferred route.

Use real anchors with href destinations for navigation. Google’s crawlable link guidance explicitly describes standard anchor elements as the reliable pattern. A div with an onclick handler can look identical and expose less information to crawlers, keyboards, assistive technology, and link-analysis tools.

The architecture should answer four questions without a spreadsheet:

• Where is the owner page for this intent?
• Which broader subject contains it?
• Which sibling answers are genuinely useful next?
• Can every important page be reached through normal links?

For content systems, this is where topical authority becomes technical. A topic map that never reaches the rendered navigation is only a planning artifact. The internal graph has to exist in HTML.

HTTP responses are part of the document

The URL is not the page. The response is the first version of the page.

Inspect the status, redirect target, headers, content type, body, and timing together. Common contradictions include:

• a deleted URL returning 200 OK with a “not found” template;
• a redirect chain that changes protocol, hostname, locale, and trailing slash one hop at a time;
• a canonical pointing to a URL that redirects elsewhere;
• HTML that declares noindex while a sitemap keeps submitting the URL;
• a useful page returning 5xx only to bots or during cold starts.

A tool can report each symptom separately. The real task is to restore one coherent instruction.

Semantic HTML is search infrastructure

Semantic HTML gives the document an explicit structure: navigation, main content, article, headings, lists, tables, figures, and links. It helps browsers, accessibility APIs, crawlers, extractors, and AI retrieval systems interpret the same source.

Do not turn that into a ranking myth. Replacing a div with article does not guarantee a position. The value is operational: the main subject, hierarchy, destination, and relationship become easier to detect and test.

Start with the native element that matches the function. Use headings as a hierarchy, not as a font-size switch. Use a table for tabular relationships. Use a button for an action and an anchor for navigation. Add ARIA when native HTML cannot express the required state — not as a second semantic layer over an incorrect element.

The semantic HTML guide includes an inspectable page model and a release checklist.

Rendering: compare the response with the result

Server-rendered HTML gives crawlers and users an immediate document. Client-side JavaScript can enhance it, but it also creates another failure surface.

Google can process JavaScript, but its JavaScript SEO documentation treats crawling, rendering, and indexing as distinct phases. That is reason enough to test both the response HTML and rendered DOM.

Compare them for:

• title, description, canonical, robots directives, and language;
• the H1 and primary body copy;
• crawlable internal links;
• structured data that describes visible content;
• images and their meaningful alternatives;
• parity across desktop and mobile routes.

JavaScript is not automatically an SEO problem. Unobserved dependency on JavaScript is. Use the crawl, render, and index diagnostic to find the first failed transition instead of treating every JavaScript symptom as the same issue.

Canonicalization is selection, not redirection

A canonical signal asks a search engine to consolidate duplicate or near-duplicate URLs. It does not move a user and it is not an access-control mechanism.

Choose one indexable owner URL and align the signals around it: internal links, sitemap entry, redirect behavior, canonical tag, content, language, and structured data identifiers. Mixed signals force the search engine to resolve a disagreement you created.

Use the canonical tag protocol to inspect the complete URL cluster and define a production acceptance condition.

Typical sources of accidental duplication include tracking parameters, filters, print views, case variants, slash variants, locale fallbacks, staging hosts, and CMS-generated archives. The right treatment varies. Some routes should redirect, some should canonicalize, some should remain distinct, and some should never be generated.

Indexing is a decision, not a delivery receipt

Submitting a URL in a sitemap does not require a search engine to index it. A sitemap is a discovery and metadata signal. Index selection still considers duplication, content value, response quality, directives, and other system-level judgments.

The XML sitemap guide treats the file as an inventory contract: canonical, indexable, successful owner URLs in; redirects, errors, noindex pages, and alternate states out.

Treat “Crawled — currently not indexed” as a state that needs evidence, not a universal content rewrite. Confirm the live response, selected canonical, template pattern, uniqueness, internal graph, and actual demand before deciding what to change.

The practical order is:

1. verify the inspected URL and live response;
2. confirm that indexing is intended;
3. resolve conflicting directives and canonicals;
4. compare the page with the selected canonical and competing owner pages;
5. improve or consolidate only after the technical state is clear.

Diagnose the first broken state

The fastest technical audit is URL-level before it is sitewide. Pick one commercially important URL and follow it through discovery, fetch, render, index, and serving.

This prevents a common audit failure: exporting 40,000 rows before proving what any one row means. Once the failure is understood on a representative URL, test whether it repeats by template, directory, locale, parameter pattern, or release.

Evidence should be reproducible. Record the tested URL, timestamp, user agent or tool, response, rendered state, expected state, and owner. Screenshots are useful context; raw responses and logs are stronger diagnostic artifacts.

Performance is a user constraint with search consequences

Core Web Vitals are field metrics, not a decorative Lighthouse badge. Use real-user data when available and lab traces to explain why a field metric is poor.

For LCP, identify the actual element, its discovery timing, resource weight, server delay, and render delay. For INP, trace the interaction and main-thread work. For CLS, locate the element that moved and the missing size reservation or late injection.

Do not ship a global optimization because one synthetic run suggested it. Fix the template and resource path that create the observed delay, then verify the distribution over time.

Structured data describes; it does not invent

Structured data should identify the visible page, its entities, and supported relationships. It is not a place to add claims the user cannot see.

Keep identifiers stable, use canonical URLs, connect the author and organization consistently, and validate both syntax and eligibility. A valid graph can still be irrelevant to a supported search feature. A rich-result test is not proof that a result will appear.

This site uses article, breadcrumb, person, website, and dataset entities where the page supports them. The same principle should guide an ecommerce implementation: Product markup belongs on a real product page with matching visible facts, not on a generic category template.

Platform constraints change the implementation, not the model

Shopify, WordPress, and WooCommerce expose different controls, but the diagnostic chain stays the same.

• Shopify: work with generated routes, product and collection duplication, theme rendering, faceted URLs, and the platform’s robots controls.
• WordPress: control plugin overlap, archive taxonomies, theme markup, feeds, REST-rendered blocks, and caching layers.
• WooCommerce: treat it as ecommerce architecture on WordPress — products, categories, attributes, filters, variants, stock states, and plugin interactions.

That is why WooCommerce belongs under the future ecommerce SEO hub. Its central problems are commercial taxonomy, faceted navigation, product lifecycle, and duplicate URL control. A standalone WooCommerce hub becomes useful only when the site has enough genuinely platform-specific material to support it.

Turn the audit into a release system

A useful audit ends with a verifiable change set, not a 120-slide diagnosis.

Each issue should contain:

• affected template or URL pattern;
• observed and expected behavior;
• evidence and reproduction steps;
• search and business impact;
• proposed owner and release risk;
• acceptance test and monitoring signal.

Prioritize by blocked value, blast radius, confidence, and implementation cost. A broken canonical across every product page beats 600 isolated title-length warnings. A server error on the revenue template beats a theoretical crawl-budget concern on a 300-page site.

Technical SEO works when releases make the system more coherent and monitoring proves it stayed that way.