Written by 4SYSTEMPublished on Updated on
9 min read
A technical SEO audit is used to identify what is preventing a useful page from being accessible, understood or discovered, and then to provide a verifiable correction. An export of errors is not enough: the same defect can affect a strategic template or a deliberately excluded URL. Start with important paths and recent changes, not alert length.
Prioritize a reproducible block on an important family before an isolated warning. Separate the observation, the hypothesis and the decision; each correction must have proof of acceptance testing. A successful current test does not necessarily describe the situation recorded by Google.
Framing the audit by template and professional background
Gather the list of templates, the URLs important to the activity, the correspondence between old and new addresses, the deployment date and the planned exclusions. Also request access to configurations, Search Console and useful server logs. The business manager must specify the families to be kept accessible and the pages reserved or removed.
For important journeys, also specify the dependencies: internal search, filters, API products or forms. You will be able to distinguish the defect in the template from a breakdown in the service that supplies it.
Build a template-oriented sample: family page, product pages, variant, pagination and entry from the navigation. For each sensitive template, take one apparently healthy page and one suspicious page. Add cases changed during redesign, rather than only selecting the first URLs in a crawl.
Record for each URL the business role, expected behavior, and reason for selection. A page deliberately deleted does not require the same correction as an active family that has become inaccessible. If the defect seems common to the model, extend the check to its variants before speaking of a global incident. A sample allows you to find shared causes, not to measure their presence across the entire site.
Check HTTP access before SEO signals
Make a GET request first and keep the HTTP code, headers, received body, final URL, and test time. Also note the user agent and the presence of an intermediate cache so that the technical team can exactly reproduce the request in question.
Note each redirection: arriving on a functional page can hide a bad destination. Compare the old address, the new one and the internal links that use them. Also check that the permanent or temporary nature of the redirection corresponds to the planned migration.
A status 200 does not guarantee indexing; an empty or error-like response may be treated as a soft 404.[18] So look at the content delivered, not just the green color of the crawler.
Server errors 5xx and code 429 may temporarily slow down Google crawling; content received with a status 5xx is ignored.[18] For a large template, check the routing, cache, application and availability of its dependencies with the technical team. Repeat the test under the documented conditions and reconcile it with the logs. A server error can be transient: a successful current test does not invalidate a previous failure, and the opposite is possible.[23]
Control robots, noindex and canonical without confusing them
Then check the access authorized by robots.txt, then the indexing directives in the headers and the HTML. Note their origin: global setting, template, extension or publication parameter. Compare them to the business decision recorded at the outset.
A robots.txt block does not replace a noindex: if Google cannot crawl the page, it cannot read this directive, and the URL may still appear in the results.[23] So don't remove a rule without understanding the purpose of the exclusion.
Then examine the declared canonical and the corresponding destination: equivalent page, available, consistent with internal links. In Search Console, distinguish the declared canonical from the one chosen by Google. This choice can be consulted in the indexing data; the live test cannot predict it.[23]
Keep the captures and the report date: they describe a recorded state, sometimes before deployment. If the problem only concerns one address, use the diagnosis of a page missing from Google to delve deeper into its condition without transforming this isolated case into a verdict on the entire catalog.
Track rendered content and navigation paths
Compare the HTML received and the rendering: title, main content, products displayed and navigation links. An accessible but empty page deserves a separate incident from a simply slow page. Document error resources, application calls, and conditions necessary for content to appear.
For the mesh, start from a known public entrance and follow the path towards the family, then towards its files. Look for obsolete destinations and clickable elements that don't expose a usable address. Google recommends links HTML <a> with an attribute href ; a JavaScript event alone does not guarantee reliable URL extraction.[17] A button usable with the mouse is therefore not enough to validate the exploration path.
A link added by JavaScript may be crawlable if it uses this markup.[17] Also check its text in the rendered HTML. Google recommends that an important page receive at least one link from another page on the site.[17] Your control should identify the specific starting page and link, not just see that the destination is in a sitemap.
Prioritize technical audit incidents SEO
To sort the findings, use three qualitative criteria: importance of the route, confirmed extent and strength of the evidence. This grid is a working method, not an official Google scale.
| Decision | Status | Expected sequel |
|---|---|---|
| Process first | Inaccessible business template or missing main content | Open a technical incident and secure the deployment |
| Plan quickly | Family accessible but deprived of relevant internal paths | Fix navigation component and check its variants |
| Examine without presumed emergency | Isolated warning without blocking reproduced | Confirm the purpose of the page and the actual effect |
Do not infer severity from the number of alerts. A structured data warning does not, on its own, demonstrate a lack of access to the catalog. Conversely, an error common to a strategic model merits investigation even if it appears rarely in the sample. Assign each incident to an actionable manager, with an explicit dependency and closure condition.
Incident sheet: a fictitious catalog after redesign
Here is an entirely fictitious case, unrelated to a customer of 4SYSTEM. After a redesign, the “lighting” family is no longer connected from public navigation; the “storage” family returns a server error. The following observations are premises for the exercise, not actual audit results.
| Field | Navigation incident | Server incident |
|---|---|---|
| Perimeter | Luminaire family, navigation component | Storage family, category template |
| Business impact | Access to the choice of luminaires interrupted from the catalog | Family consultation impossible |
| Reproduction | From the catalog, look for the link to /luminaires/ in the rendered HTML; notice its absence | Send a GET request to /rangements/ ; keep the response 5xx and its timestamp |
| Hypothesis | Family omitted in menu configuration | Failing route or application dependency after migration |
| Proposed fix | Restore a descriptive link with href towards the working family | Restore the expected route if its fault is confirmed; otherwise correct the identified dependency |
| Expected acceptance testing | Redo the route; find the link provided and an accessible destination | Repeat query; get expected content without server error |
| Responsible and proof | Front team; capture the link and export the rendered HTML | Application team; headers, content and redacted log extract |
The server first goes into the intervention queue: it directly blocks the consultation. The mesh keeps its own ticket. The hypotheses remain open as long as no technical verification confirms them; the form must not arbitrarily attribute a cause to the deployment.
Validate the correction without confusing test and indexing
Before going into production, agree on the acceptance testing with the manager: sample URL, template variants, expected result and parts to keep. After correction, replay the initial reproduction, then check a neighboring page for regression. Archive the responses, the HTML rendered, the version deployed and the date of the checks.
The Search Console live test examines the current page, while the inspection report describes the known version of Google.[23] A valid test confirms access for the inspection tool, not future indexing; it also does not check referring pages.[23] The mesh acceptance testing must therefore remain separate.
Close the technical correction on this evidence, then distinctly follow the evolution of the recorded data. Don't leave a ticket open just because Google has not yet reflected the change. In shared rooms, remove unnecessary session IDs and personal data; This technical diagnosis does not constitute validation of GDPR compliance.
Frequently asked questions
How to control a password-protected pre-production?
With authorized access, check responses, directives, and rendering locally, then prepare a acceptance testing on the public environment. The Search Console live test requires a page that is accessible over the Internet without a connection.[23] Do not open the entire preproduction for this check alone: keep its protections and test the public configuration at deployment time.
Should we remove the noindex from all facets?
No. Decide with the business which combinations correspond to a standalone offer and which are only used for filtering. Document this intention before any global changes. For a facet intended to remain excluded, check the directive actually delivered and the necessary user paths. The goal is a consistent configuration, not automatic opening of all variations in the catalog.
What to do when a correction depends on a service provider?
Send a reproducible sheet, without presenting the hypothesis as a certain cause. Specify the component concerned, the expected behavior, the available evidence and the person responsible for the acceptance testing. Ask if a reversible temporary measure is possible, with its documented risk. Keep technical blocking, waiting for a response and final validation separate to avoid premature administrative closure.
Next action: open a verifiable incident
Start with a priority family: choose its witness URLs, check access, then fill in an incident sheet with an observable acceptance testing. Expand only when the evidence shows a shared fault. If you wish to frame the intervention between business and technical teams, the web services and SEO of 4SYSTEM make it possible to discuss the scope, the necessary access and the expected deliverable.
Sources
- SEO Link Best Practices for Google | Google Search Central | Documentation | Google for Developers (accessed 2026-10-08)
- How HTTP Status Codes Affect Google’s Crawlers | Google Crawling Infrastructure | Crawling infrastructure | Google for Developers (accessed 2026-10-08)
- URL Inspection tool - Search Console Help (accessed 2026-10-08)
