A technical SEO audit should check things in the order a search engine meets them: can it crawl the site, can it index the right pages, does it understand which version of each page is the real one, and can people use those pages quickly on a phone. Fix access and indexation problems first, because no amount of content or schema work helps a page Google cannot reach or chooses not to index.
This is the sequence we follow at DA WebTech, whether the site is a ten-page PHP brochure site or a WooCommerce store with thousands of URLs.
What do you need before starting a technical SEO audit?
You need access to real data, not just a crawler. Without Google Search Console and a full crawl, an audit is guesswork dressed up as a report.
- Google Search Console, verified as a domain property so you see every protocol and subdomain together.
- A desktop crawler such as Screaming Frog or Sitebulb. Run one crawl that respects robots.txt, then a second that ignores it, so you can see exactly what is being blocked.
- Server or hosting access: at minimum the ability to read .htaccess or Nginx rules, and ideally raw access logs to see what Googlebot actually requests.
- A list of the pages that make money: core service pages, top product categories, quote and contact pages. These get checked first and most carefully.
Record the current state before changing anything. Export indexed page counts, top queries and Core Web Vitals status so you can prove later that fixes worked.
Step 1: Can search engines crawl the site?
Crawlability is the foundation of everything else. Confirm that the pages you want found are reachable through ordinary links and are not blocked by robots.txt or server errors.
robots.txt
Open /robots.txt on your domain and read every line yourself. Common finds include a leftover Disallow: / from a staging server and blocked CSS or JavaScript folders that stop Google rendering the layout. Remember that robots.txt controls crawling, not indexing.
Crawl depth and orphan pages
Compare your crawl against the XML sitemap and the pages Search Console reports as indexed. URLs that appear in the sitemap but never in the crawl are orphans, meaning no internal link points to them. Important pages should sit within roughly three clicks of the homepage.
Server health
Check the Crawl Stats report in Search Console for spikes in 5xx errors, host availability problems and rising average response times.
Step 2: Are the right pages indexed, and only those?
The goal is not maximum indexation. The goal is to get the pages that deserve to rank indexed, and keep thin, duplicate or utility URLs out of the index.
Open the Page indexing report and work through each reason listed under pages that are not indexed. They mean different things:
- Crawled, currently not indexed usually points to thin, duplicated or low-value content. Improve it, merge it or remove it.
- Discovered, currently not indexed often means Google has not prioritized crawling the URL yet, which can reflect weak internal linking or, on large sites, too many low-value URLs competing for attention.
- Excluded by noindex tag: confirm every single one is deliberate. A noindex accidentally left on a live service page after launch is one of the most expensive mistakes in SEO.
- Duplicate without user-selected canonical means you have not told Google which version you prefer, so it picked one for you.
Then look for index bloat: tag and author archives, internal search result pages, filter and sort combinations on e-commerce category pages, and old printer-friendly URLs. Decide case by case whether to noindex, canonicalize, block or remove each pattern.
XML sitemaps
A sitemap should list only canonical, indexable URLs that return a 200 status. Crawl the sitemap URLs on their own and flag any that redirect, return 404, carry noindex or canonicalize elsewhere. Confirm it is referenced in robots.txt and submitted in Search Console. Larger sites benefit from separate sitemaps for pages, posts, products and categories, so you can compare indexation rates by section.
Step 3: Do canonicals, redirects and status codes agree?
These three signals should all point to the same preferred URL. When a link redirects to page A, the sitemap lists page B and the canonical names page C, Google is left to guess.
Canonical tags
Every indexable page should carry a self-referencing canonical with the full preferred URL: correct protocol, consistent www or non-www, consistent trailing slash. Check that paginated pages do not all canonicalize to page one, and that no canonical points at a redirected, broken or noindexed URL.
Redirects
Test the four versions of your homepage (http and https, with and without www) and confirm each resolves to one final URL in a single hop. Find redirect chains and loops, and update internal links so they point straight at final URLs. After any redesign or migration, compare old URLs from Search Console exports or backups against the new site to catch pages that now return 404 when they should 301 to a relevant replacement.
Status codes
List every internal URL returning a 4xx or 5xx code. Watch closely for soft 404s, which are pages that say nothing was found, or are nearly empty, but still return 200. Use 410 only for content you removed on purpose and do not plan to replace.
Step 4: Does internal linking support your priority pages?
Internal links tell search engines which pages matter and how your topics connect. They are also the one ranking lever you fully control.
- Count inbound internal links to each money page. Your main service or category pages should be among the most linked URLs on the site.
- Use descriptive anchor text such as “industrial valve manufacturing” rather than “click here”, without forcing the identical keyword into every link.
- Fix internal links that point at redirects or broken pages.
- Confirm navigation uses real
a hreflinks, not JavaScript click handlers that crawlers may not follow.
Step 5: Structured data, Core Web Vitals, mobile and JavaScript
Once access and indexation are sound, check how well Google can understand each page and how well real users experience it.
Structured data
Run each key template through the Rich Results Test and the Schema Markup Validator. Look for errors, markup describing invisible content, and duplicate Organization data from multiple plugins.
Core Web Vitals
Use field data from the Core Web Vitals report and PageSpeed Insights rather than relying only on lab scores. The three metrics are Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. Group problems by template: if the product template fails, one fix improves every product URL at once.
Mobile parity
Google uses mobile-first indexing, so the mobile version is the version that counts. Confirm that body content, internal links, structured data and meta tags match between mobile and desktop, and that nothing important is hidden behind a desktop-only element.
JavaScript rendering
Compare raw HTML with the rendered HTML in the URL Inspection tool. If titles, body copy or links appear only after scripts run, indexing can be delayed or incomplete. Server-side rendering or pre-rendering is the safer pattern for content that needs to rank.
Hreflang, only if relevant
If you serve several languages or countries, every hreflang set must be reciprocal, use valid language and region codes, point at canonical URLs returning 200 and include a self-reference. Most single-market Indian business sites do not need hreflang at all.
How should you prioritize what you find?
Rank each issue by its effect on revenue pages, multiplied by the number of URLs affected, and then weigh the effort to fix it. A simple matrix keeps the conversation with developers focused.
| Issue | Typical consequence | Priority |
|---|---|---|
| Accidental noindex or robots.txt block on key pages | Pages drop out of search entirely | Critical, fix immediately |
| Frequent 5xx errors or very slow server response | Reduced crawling and lost visitors | Critical |
| Missing or broken redirects after a migration | Lost links and rankings from old URLs | High |
| Conflicting canonicals or duplicate site versions | Wrong URL ranks or signals are split | High |
| Orphaned or deeply buried money pages | Weak discovery and weak internal authority | High |
| Core Web Vitals failing on main templates | Poorer experience and conversion on many URLs | Medium |
| Index bloat from tags, filters or search pages | Crawl attention wasted on low-value URLs | Medium |
| Internal links pointing through redirect chains | Slower crawling, minor signal loss | Medium to low |
| Missing or invalid structured data | Lost eligibility for some rich results | Low to medium |
The order rarely changes: anything blocking crawling or indexing comes before speed, and speed usually comes before schema. A thorough SEO audit should hand developers this list as tickets, not as a hundred-page PDF nobody reads. For WordPress sites where speed is the main bottleneck, WordPress speed optimization is often the most efficient place to start once indexation is clean.
Key takeaways
- Audit in the order search engines work: crawl, index, canonicalize, then render and experience.
- Start with Search Console data and a full crawl, and record a baseline before changing anything.
- Aim for the right pages in the index, not the most pages.
- Make sitemaps, canonicals, redirects and internal links all point at the same preferred URLs.
- Fix problems by template so one change improves many pages.
- Prioritize by business impact and scale, not by how alarming a tool’s warning looks.
Next steps
Run through the first two steps yourself this week; robots.txt and the Page indexing report alone often reveal the biggest problems. If you would rather have the full checklist worked through and turned into a prioritized fix list for your developers, our technical SEO service covers exactly that.
