Technical SEO: what to check first

A technical SEO audit is most useful when it connects website problems with business priorities. A long spreadsheet of warnings is not a plan. The goal is to identify what prevents people and search engines from reaching, understanding and using the pages that matter. For a service business, those pages might include its core services, location information and enquiry page. For an online store, they might include collections, products and buying guides. This guide outlines a practical sequence for investigating those pages, recording evidence and deciding which fixes deserve attention first. The examples are illustrative checks, not results from a client project.

Start with a page inventory and a clear goal

Before opening an audit tool, write down the main actions visitors should be able to complete. Then list the pages supporting those actions. Include the homepage, important service or category pages, supporting content and the contact route. Record each page's intended audience and purpose. This makes it easier to distinguish a serious problem from an irrelevant warning. A broken enquiry link on a commercial page deserves attention before an unused demo page's missing description. Keep the inventory manageable at first. Investigate the main templates, identify recurring problems, and then expand the review across similar pages.

Check the actual server response

Open each important URL while logged out and test its response, rather than assuming that a WordPress Published label means the page works for everyone. Follow navigation links as a visitor would. Check whether the destination is a usable page, an unexpected redirect, a login screen or an error. Google's technical requirements include crawler access, a successful HTTP response and indexable content. If a page returns a server error, collect the URL, time and steps that reproduce it. Ask the hosting or development team to inspect logs. Avoid randomly disabling plugins without recording what changed and whether the problem can be reproduced.

Separate crawling from indexing

Crawling and indexing are different questions. A page can exist for visitors without being a page you want included in search. Review robots.txt and page-level indexing directives with that distinction in mind. Google needs to crawl a page to discover its noindex directive; blocking the URL in robots.txt is not an equivalent replacement. For important pages, inspect the rendered output and Search Console evidence. For pages intended to stay out of search, document why. An internal utility page and a public service page should not automatically receive the same settings. Make changes page by page or by a clearly understood template rule.

Review canonical URLs and duplicate routes

A website may expose similar content through several URLs. Tracking parameters, filter combinations and alternate hostnames can complicate the picture. First identify which version you want users and search engines to treat as the main page. Then review canonical signals, redirects and internal links together. Google describes canonical annotations as signals rather than an absolute command. A practical review therefore considers whether the preferred page is accessible and whether the website consistently links to it. Do not redirect unrelated pages to the homepage simply to remove errors. Preserve useful destinations and choose relevant replacements when a page has genuinely moved.

Test navigation and contextual internal links

Navigation should help a visitor find the next useful page without guessing. Check the header, footer, mobile menu, buttons and contextual links inside articles. Read the link text on its own: does it describe where someone will go? Google recommends crawlable links and informative anchor text. For a portfolio, an article about technical SEO can naturally link to the relevant service and contact pages. For a store, a buying guide can connect to a relevant collection. Avoid adding dozens of unrelated links just because a tool reports a low link count. Make each connection useful to the reader.

Inspect templates on mobile as well as desktop

Use the website on a phone-sized screen and complete the main task. Look for clipped headings, overlapping navigation, horizontal scrolling and buttons that are difficult to tap. Check whether images load, text remains readable and forms can be completed. These checks are especially important after a theme change, page-builder import or plugin update. A desktop preview can hide a mobile layout problem. Record the device size and affected template so a developer can reproduce the issue. Treat performance measurements as diagnostic evidence, and compare them with what users experience rather than chasing a score without a clear reason.

Prioritize fixes by impact and confidence

For every finding, record the affected URL, observed behaviour, intended behaviour, evidence and recommended owner. Classify the issue by how directly it disrupts access, understanding or a business action. A widespread broken template requires a different response from a cosmetic inconsistency on one article. Also record confidence: have you verified the issue or only seen a tool warning? Assign a next step to uncertain findings, such as checking logs or inspecting rendered HTML. A concise, verified list is easier to implement than a large collection of untested assumptions. Agree on the repair order before making changes across the site.

Validate the repair and keep a change log

After a fix, repeat the original test. Check the same URL while logged out, use the same navigation path and inspect the affected mobile layout. If caching is involved, distinguish a stale cached page from the new output. Confirm that unrelated pages still work. Keep a short record of what changed, when it changed and how it was verified. Search Console can support follow-up investigation, but a repaired page is not guaranteed immediate indexing or higher rankings. Technical work removes obstacles and supports a functioning website; its commercial value should be assessed alongside enquiries, purchases and the usefulness of the content.

A practical handover checklist

A useful handover lets someone else continue the work without repeating the investigation. Include screenshots where they clarify the problem, but accompany them with reproducible steps. Specify the exact page, not only the general template name. State whether the proposed fix changes a URL, navigation, indexing directive or page content. Identify any dependency, such as a hosting investigation before a WordPress configuration change. Keep backups or a rollback route for meaningful changes. Finally, assign an owner for checking the live result. An audit is complete only when its recommendations can be understood, implemented and verified. The next step is a focused assessment of your own website's most important pages.

Example: investigating a broken contact route

Imagine a visitor reading an article, selecting Contact and landing on an error page. First record the link that was clicked and the final destination. Next locate the intended contact page in the content system and compare its current URL and publication status. Test that destination directly while logged out. If the correct page works, update the faulty link and check other templates using it. If it does not work, investigate the page or server before changing navigation. Finally, repeat the visitor journey from the original article. This process shows why a precise investigation matters: the visible theme on an error page does not establish that the theme caused the failure.

References: Technical requirements · Canonical URLs · Noindex · Internal links