Complete Guide to Technical SEO: Audit Your Site Like a Pro

No amount of good content will rank if search engines cannot crawl, index and render your pages. Technical SEO is the part of the job that decides whether Google ever sees your content the way a user does. This is a working audit process: what to check, the exact tool and setting to use, the fix for each finding, and the issues that show up most often on Indian sites.

The audit framework: crawl, index, render, quality

Break the audit into four phases and work through them in order. Crawl problems make indexing problems irrelevant; indexing problems make performance work pointless. Fix upstream issues first.

Phase 1: Crawl analysis

Before fixing anything, see what search engines actually fetch. Crawl the site with Screaming Frog SEO Spider (free up to 500 URLs, paid licence above that) or use the URL Inspection tool and Pages report in Google Search Console. Look for:

• 4xx and 5xx responses. In Screaming Frog, filter the Response Codes tab. A 5xx means a server-level failure and should be fixed first.
• Redirect chains. A URL that hops A → B → C wastes crawl budget and leaks link equity. Use the "Redirect Chains" report under Reports > Redirects. Collapse every chain to a single 301.
• Orphaned pages. Pages with zero internal links pointing to them. Crawl with the XML sitemap and Google Analytics connected, then check the "Orphan URLs" tab so Screaming Frog can compare crawled-vs-known URLs.
• Blocked resources. CSS, JS or images disallowed in robots.txt. If Google cannot fetch your CSS and JS, it renders a broken version of the page. Confirm with the "Test live URL" option in URL Inspection and look at the rendered screenshot.

One practical robots.txt rule: never disallow /wp-content/ or your theme/asset folders. That single line blocks the files Google needs to render the page correctly, and it is one of the most common self-inflicted wounds on WordPress sites.

Phase 2: Indexability check

Now confirm the pages you want indexed can be indexed, and the ones you do not want indexed are excluded:

• No accidental <meta name="robots" content="noindex"> on money pages. After a staging-to-live migration this is the single most common catastrophic mistake, the whole site goes noindex because the "Discourage search engines" box was left ticked in WordPress (Settings > Reading).
• Canonical tags resolve correctly. Every page should be self-referencing unless it is a deliberate duplicate pointing to a master. A canonical that points to a redirected or 404 URL effectively de-indexes the page.
• XML sitemap lists only indexable, canonical, 200-status URLs, and excludes tag, archive and search pages. Submit it in Search Console (Sitemaps) and in Bing Webmaster Tools.
• In the Search Console Pages report, work through the "Why pages aren't indexed" reasons. "Discovered, currently not indexed" usually means thin content or too few internal links; "Crawled, currently not indexed" usually means Google saw it and judged it low value or duplicate.

Phase 3: Core Web Vitals and rendering

Run your top pages through PageSpeed Insights. The numbers that matter are the field data (real Chrome user data) at the top, not the lab score. Targets:

• LCP (Largest Contentful Paint) under 2.5s
• INP (Interaction to Next Paint) under 200ms, this replaced FID as a Core Web Vital in March 2024
• CLS (Cumulative Layout Shift) under 0.1

On most Indian small-business sites the LCP element is a hero image or banner. Three fixes handle the majority of cases: serve images in WebP/AVIF, add explicit width and height attributes so the browser reserves space (this also fixes CLS), and preload the LCP image:

<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

Pick the top 10 pages by organic traffic and check the LCP element on each. It is usually the same image type repeated across a template, so one fix improves many URLs at once.

Phase 4: Content quality signals

Technical quality extends past speed:

• Duplicate content. Run the site through Siteliner to find internal duplication. Watch for the same product description repeated across variant URLs.
• Keyword cannibalisation. Multiple pages targeting one query. In Search Console's Performance report, filter by a query and check the Pages tab, if several URLs split impressions for the same term, consolidate or differentiate them.
• Missing or duplicate titles and meta descriptions. Screaming Frog flags these directly in the Page Titles and Meta Description tabs.
• Heading hierarchy. One <h1> per page, no skipped levels.
• Missing image alt text. Low effort, helps accessibility and image search.

Schema markup audit

Structured data does not directly raise rankings, but it earns rich results that lift click-through rate from the same position. Check what you have implemented against what each template should carry:

• Article or BlogPosting on blog posts
• FAQPage on pages with a genuine Q&A section
• LocalBusiness on contact and location pages: for an Indian business include addressCountry: "IN", the correct addressRegion (state), and a valid telephone in international format (+91...)
• BreadcrumbList sitewide
• Product with AggregateRating only where real, on-page reviews exist

Validate every template with Google's Rich Results Test and the Schema Markup Validator (schema.org). A word of caution: only mark up content that is actually visible on the page, and never add review or rating schema for ratings you cannot prove, Google issues manual actions for this and it is not worth the risk.

Mobile usability

Mobile-first indexing is the default, so Google ranks the mobile version of your page, not the desktop one. Check:

• Viewport set: <meta name="viewport" content="width=device-width, initial-scale=1">
• Touch targets at least 48px and spaced apart
• Body text at least 16px, no horizontal scroll
• Parity between mobile and desktop content. If your theme hides or lazy-loads content behind a "read more" tap that never loads in the DOM, Google may not index it. Compare the rendered HTML on mobile vs desktop.

Test on a real mid-range Android phone on a mobile network, not just Chrome DevTools. DevTools hides the real-world latency that Indian users on 4G actually experience.

Security check

• Valid SSL sitewide; every HTTP URL 301-redirects to HTTPS
• No mixed content (an HTTPS page loading an HTTP image, script or stylesheet)
• Security headers present: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options
• No "Security Issues" flagged in Search Console (hacked content, malware)

How to run your first audit, day by day

If you have never done a full audit, the checklist feels overwhelming. Here is a practical seven-day sequence that keeps it manageable:

1. Day 1: Crawl and snapshot. Run Screaming Frog on the full site (or a 500-URL sample if large) with default settings. Export to a spreadsheet. Pull parallel data from Search Console's Pages and Performance tabs. This is your baseline.
2. Day 2: Triage errors. Filter the crawl for 4xx and 5xx. Group them: broken internal links, dead external links, old URLs that should redirect. Fix 5xx first, they signal server problems.
3. Day 3: Fix indexing. Work the Pages report. Investigate every "currently not indexed" reason. Usually thin content, duplicate canonical, or near-zero internal links.
4. Day 4: Core Web Vitals. Top 10 pages by organic traffic through PageSpeed Insights. Note the LCP element on each; the fix usually generalises across a template.
5. Day 5: Schema. Run the Rich Results Test on one representative page per template (homepage, blog post, product, service). Fix errors first, then enhance valid-but-incomplete markup.
6. Day 6: Mobile. Open the live site on a real Android phone. Tap through five typical journeys. Whatever feels janky is usually the same thing hurting rankings.
7. Day 7: Compile and prioritise. One document, sorted by impact, not ease of fix. Put the work on a calendar across the next 30–60 days.

Five findings that show up most on Indian sites

Across Indian agency, e-commerce and blog sites, a handful of issues recur. If you check nothing else, check these:

1. Hreflang missing or wrong. Many Indian sites serve both English and Hindi (or a regional language) but never declare it, so Google cannibalises or under-indexes the variants. The correct pattern for an English/Hindi pair targeting India:

   <link rel="alternate" hreflang="en-in" href="https://example.in/page" />
   <link rel="alternate" hreflang="hi-in" href="https://example.in/hi/page" />
   <link rel="alternate" hreflang="x-default" href="https://example.in/page" />

   Every variant must reference every other variant, including itself.
2. Mobile renders less content than desktop. Collapsed accordions that only load on tap can hide content from the mobile-first index. If it is not in the rendered DOM, treat it as invisible to Google.
3. Hosting outside India with no CDN. A US-hosted site without a CDN serves Indian users from across an ocean, and LCP suffers. Put Cloudflare (the free plan works) or BunnyCDN in front, or host closer to your audience, AWS Mumbai (ap-south-1), or Indian hosts with Mumbai/Chennai/Hyderabad data centres.
4. Junk pages indexed by accident. Tag, archive, author and internal search-result pages are indexable by default in many CMS templates. They are thin-content liability and waste crawl budget. noindex them unless each has genuine unique editorial content.
5. Duplicate H1s on listing pages. A common WordPress theme bug: the page title and each post-card heading all use <h1>, so Google sees several H1s on one category page. View the rendered source and count.

Build an action plan

After the audit you will have a list of issues. Prioritise by impact:

• Critical: anything blocking indexing entirely: rogue noindex, canonical to a redirect/404, important pages disallowed in robots.txt.
• High: Core Web Vitals failures on traffic pages, crawl errors on high-value URLs, security issues.
• Medium: schema gaps, duplicate content, heading hierarchy.
• Low: missing alt text, meta description tweaks, minor speed gains.

Ship the top 10 highest-impact fixes in month one, measure, then continue. A backlog of 200 medium items paralyses most teams; compounding small wins beats one remediation sprint that never finishes. If you would rather hand this off, this is exactly the kind of work covered by our SEO services, or get in touch for a site-specific audit.

The toolkit

• Google Search Console: free, the source of truth for indexing, crawl and performance data
• Bing Webmaster Tools: free, also feeds some AI search engines
• Screaming Frog SEO Spider: the standard crawler; free to 500 URLs
• PageSpeed Insights / Lighthouse: free Core Web Vitals testing (field + lab data)
• Rich Results Test + Schema Validator: free structured-data validation
• Ahrefs / Semrush Site Audit: paid; score findings and track progress over time

How often to re-audit

A full audit every six months suits most sites. Between audits, run lighter monitoring:

• Turn on Search Console email alerts for every category.
• Check Core Web Vitals on your top 10 pages monthly.
• Crawl your top 50 pages quarterly to catch new redirect chains and broken internal links early.

A small problem caught early is an hour of work. The same problem caught after six months of compounding can need a rebuild.