Start with the problem you can demonstrate
If a page is missing from search, making it faster may be sensible, but it does not explain why it is missing. If the server returns an access challenge to a crawler, rewriting the title is unlikely to resolve that restriction. Technical SEO starts by separating symptoms from the mechanisms that produce them. Otherwise, teams can spend weeks improving something that was never the cause.
I work through discovery, access, rendering, indexability and the consistency of the site's signals before deciding which change belongs in a brief. These are connected stages, but they are not interchangeable. A URL can be discovered without being fetched. A fetched page can be excluded from indexing. An indexed page can still be a poor answer to a particular search.
The guides here are organised around those distinctions. Use them to investigate a specific failure or to build a repeatable audit process. They explain the observations that support a conclusion, the checks that could disprove it and the conditions that should be met before an issue is closed. That last part matters: a recommendation is only useful when somebody can verify the result.
Crawling, indexing and the limits of a crawl
The crawling and indexing guides cover how URLs are found, what happens when they are requested and which signals influence the version a search engine may retain. Start here when important pages are absent from search, unwanted URLs are being discovered or the site's indexable inventory does not match its purpose.
A crawler sees the links and responses available under its configuration. It does not automatically know every URL the business has published, every page users visit or the precise decisions Google has made. Reconcile the crawl with sitemaps, Search Console and other available records. Record the collection dates so that a difference between datasets is not mistaken for a technical defect.
Two useful starting points are diagnosing an indexing problem and understanding the distinction between crawl restrictions and indexing instructions. There is no benefit in applying a robots.txt block when the intended outcome requires Google to fetch a noindex instruction. Decide what the URL should do before choosing the control.
Rendering and performance are separate investigations
A website can look complete in your browser while sending very little useful content in its initial response. Conversely, a server-rendered page can expose all its content and still feel slow to use. The JavaScript SEO cluster and the performance guides treat these as related but distinct investigations.
For rendering, compare the response HTML with the DOM produced under a defined test condition. Check whether essential copy, links, metadata and structured data survive. Test a direct visit to a deep URL rather than relying on navigation from the homepage. A successful client-side route change does not prove that the same URL has a useful server response.
For performance, begin with the experience you are trying to improve. Loading, responsiveness and layout stability have different causes and different diagnostic evidence. Use laboratory traces to investigate a mechanism and field data to understand the experience of real visits. Do not present a single Lighthouse run as a measurement of every visitor, or a field-data gap as proof that a page is fast.
Architecture should make the important routes obvious
The site architecture and internal linking guides look at the routes between pages, the purpose of each destination and the controls around large URL spaces. A tidy folder structure helps people understand a site, but folders alone do not create a useful crawl path. The links in the HTML have to do that work.
My preference is to give supporting pages a clear relationship with their parent topic and a small number of relevant next steps. An article about canonical conflicts may need to point to parameter handling, duplicate content and indexation diagnosis. It does not need a link to every service on the website. The anchor should describe the destination in the context of the sentence.
On larger sites, architecture also includes decisions about pagination, filters, internal search and generated combinations. These features can produce more URLs than the business intends to maintain. The answer is not to block everything that contains a question mark. Identify which combinations deserve a search landing page, which are useful only during navigation and which should not exist at all.
Audits need a clear route into development
The technical auditing cluster explains how to collect evidence, investigate template-level patterns and turn findings into work somebody can implement. A useful ticket includes the affected scope, the observed behaviour, the expected behaviour, a reproducible example and an acceptance test. Severity labels without that information leave too much interpretation to the next person.
Prioritisation should consider exposure and confidence as well as the apparent size of the issue. A broken rule affecting every important landing page may deserve immediate attention. A tool warning affecting a deliberately excluded archive may need no development at all. Record why you reached that decision so the same warning does not restart the discussion next month.
The audit methodology also covers the baseline. Keep enough evidence to compare the implementation with the original behaviour, including test settings and sample URLs. If the crawl configuration changes between runs, report the change. A smaller issue count is not a reliable success measure when the second crawl simply examined fewer pages.
Structured data and international signals need agreement
The structured data guides focus on describing the entities that the visible page actually supports. A professional website needs consistent identity references and appropriate page descriptions. Adding every available Schema.org type does not make a graph more accurate. Unsupported claims and duplicated entities can make it less useful.
Validation has several layers. JSON can parse correctly while the vocabulary is wrong. A Schema.org-valid graph can still fall outside Google's supported search features. An eligible implementation can still produce no enhanced search result. The practical task is to keep the markup accurate, connected and maintainable, then monitor what the relevant platform actually reports.
The international SEO cluster applies the same discipline to language and regional versions. Check the actual destination, canonical choice and return annotations rather than looking only for the presence of hreflang. A correctly formatted annotation pointing to the wrong page is still the wrong implementation. Language relationships need to survive publication, redirects and subsequent content changes.
Migrations and automation should reduce uncertainty
The website migration guides cover URL inventories, redirect decisions, launch checks and post-launch monitoring. The inventory needs to reflect existing demand and useful content, not merely the pages visible in a redesigned menu. Every retained, replaced or removed URL should have an explicit decision behind it.
Make the redirect map testable before launch. Check duplicate source rules, chains, loops and destinations that do not resolve as expected. After launch, repeat the checks against the real environment and inspect representative user journeys. A correct spreadsheet cannot prove that the server loaded the intended rules, that caches have refreshed or that an edge configuration is behaving consistently.
The automation and data guides explain where scripts and APIs help, and where they can create false confidence. Automate observations that can be defined reliably. Keep a human decision around content purpose, business importance and ambiguous consolidation. A script that produces a confident answer from incomplete data has saved no useful time.
Use an evidence packet rather than another warning list
Each investigation should leave behind a small, usable evidence packet: the question, the affected examples, the observation, the proposed explanation, the implementation requirement and the test that would confirm the repair. Include what remains unknown. A search engine's indexing choice, for example, cannot be fully established by inspecting a local HTML export.
The SEO evidence workbench supports that approach with browser-based checks for exported crawl data and redirect maps. The tools distinguish between checks they can perform on a file and checks that require a live request or authenticated platform data. That makes the output easier to use responsibly in a development discussion.
You can also review my project experience and professional background. Where a guide uses invented URLs or a simplified scenario, it is an illustrative example. It is not presented as a client result. The point is to make the investigation reproducible and the reasoning open to scrutiny, rather than ask you to accept an impressive-looking number.
Frequently asked questions
Does every technical SEO warning need to be fixed?
No. Establish the intended behaviour and the affected scope first. Some warnings describe an intentional exclusion, an unsupported assumption in the tool or a low-value edge case. Document the decision and retain enough evidence for somebody else to understand why the issue was accepted, scheduled or dismissed.
Can a technically sound page still be excluded from search?
Yes. Technical accessibility removes obstacles; it does not oblige a search engine to index or rank a URL. Content usefulness, duplication, canonical selection and wider quality considerations can still influence the outcome. Separate what you have verified about the implementation from what you can observe about search visibility.
Where should I start if I already have an audit?
Pick a finding that affects an important journey and can be reproduced. Confirm the expected outcome, locate the responsible template or rule and write an acceptance test before changing it. Use that first repair to establish a practical working format for the remaining audit, instead of forwarding a large spreadsheet without context.
Are these guides tied to one CMS?
The diagnostic principles apply across platforms. Implementation ownership will differ between a simple PHP site, an enterprise CMS and a client-rendered application. Identify whether a behaviour is controlled by content, a template, application code, the web server or the delivery layer before assigning the work.