SEO Audit Checklist for Service Websites

A useful SEO audit should explain why a qualified customer may not find, trust or contact the business. It should not be a list of tool warnings without business priority. For a service website, indexing, search intent, proof, internal links, local relevance, page experience and lead handling must work together.

This checklist is designed for Indian service businesses and software companies. It separates verified defects from hypotheses and gives each recommendation an owner, impact and validation method. No audit can guarantee rankings because search results also depend on competition, demand, reputation and Google systems outside the website owner's control.

Editorial review: Reviewed on 3 August 2026 using the current VASUYASHII sitemap, service-hub structure, content inventory and lead-event workflow as first-party implementation evidence.

Audit Output Format

Every finding should include five fields:

Do not label a warning “critical” merely because a tool colours it red. A missing canonical on a money page is more important than a minor title-length preference on an unimportant archive.

1. Establish the Audit Baseline

Record the date, canonical domain, CMS/framework, analytics property, Search Console property and deployment environment. Export at least the previous three months of Search Console pages and queries when available.

Create three page groups:

• money pages: services, products, contact and high-intent commercial pages;
• support pages: guides that answer buyer and implementation questions;
• utility or demo pages: routes useful to visitors but not necessarily intended to rank.

This prevents a 404 utility route from receiving more attention than a service page with impressions and no clicks.

2. Crawlability and Index Controls

Check:

• robots.txt is accessible and does not block important routes;
• important pages do not contain noindex;
• blocked URLs are not submitted in the sitemap;
• navigation and internal links use crawlable anchors;
• important content is present in rendered HTML;
• pagination can be followed without user-only interactions;
• redirect loops and long chains do not exist.

Google's robots.txt guidance explains crawl controls. Remember that blocking crawl is not the same as removing an already known URL from the index.

3. Sitemap Quality

Open the sitemap and answer:

1. Does every URL use the final HTTPS and preferred host?
2. Does each URL return a direct 200?
3. Is each URL indexable and self-canonical?
4. Are redirects, errors, filtered states and low-value utility routes excluded?
5. Are modification dates meaningful rather than changed on every build?
6. Does the count match the intended public inventory?

Google's sitemap documentation describes sitemaps as a discovery signal, not a ranking guarantee.

This current VASUYASHII sitemap output is first-party technical evidence of the final-domain implementation used during review.

The screenshot shows current implementation evidence. It does not prove that Google has indexed every submitted URL.

4. Status Codes and Redirects

Crawl the sitemap and important internal links. Classify responses as direct success, redirect, not found, server error or blocked.

For domain consolidation, test all variants:

• http://example.com/path;
• https://example.com/path;
• http://www.example.com/path;
• https://www.example.com/path.

They should reach the preferred URL without loops. A one-hop HTTPS apex-to-www redirect is normally cleaner than a two-step HTTP chain. Preserve the path and query parameters where appropriate.

5. Canonical, Open Graph and Structured Data URLs

For representative page types, compare:

• final browser URL;
• canonical link;
• Open Graph URL;
• structured-data url or mainEntityOfPage;
• sitemap entry;
• internal absolute links.

All should use the same intended public URL. A self-canonical does not force indexing, but a wrong canonical can consolidate signals to the wrong page.

Check duplicate or near-duplicate pages before changing canonical tags. If two pages target different needs, differentiate their intent and evidence. If they are genuinely duplicates, select one primary page and plan a safe consolidation.

6. Search Intent and Page Role

For every priority URL, write one sentence:

This page helps [audience] decide or complete [specific task] at [stage].

If two URLs receive the same sentence, they may compete. For example, “website development company in Delhi” and “best website development company in Delhi” can overlap unless one is a service page and the other is an evidence-led selection guide.

Review Search Console queries for the page. Group them into informational, commercial, local and navigational intent. Rewrite the title, introduction and sections only when the query evidence and page purpose support the change.

7. Title, Description and Heading Audit

Check that each important page has:

• one descriptive title aligned with intent;
• one useful meta description that sets a truthful expectation;
• one visible H1;
• sequential headings that describe the answer structure;
• no sitewide filler appended to every title;
• no copied metadata across different pages.

Length is a diagnostic, not a rule. Rewrite clipped or vague titles first. A title that earns impressions but a weak click-through rate deserves priority over a title with no search demand.

8. Content Quality and Evidence

Assess whether the page contains original decision value. Look for:

• clear audience and problem;
• first-hand workflow or implementation evidence;
• assumptions and limitations;
• specific examples rather than generic benefits;
• complete answer to the query;
• current author and review date;
• primary sources for technical or regulatory claims;
• a useful next action.

Word count alone is not quality. A 2,000-word page built from repeated boilerplate can be weaker than a focused 1,200-word guide with a real workflow and evidence. Google's people-first content guidance recommends original, substantial content created for an intended audience.

9. Duplicate and Cannibalisation Review

Group pages by title, focus keyword, slug terms and Search Console queries. Review clusters such as city service pages, software cost guides, CRM comparisons and WhatsApp automation.

Classify each page:

• primary money page;
• supporting guide;
• distinct local page with genuine local value;
• merge candidate;
• historical page to monitor;
• low-value page that should not be promoted.

Do not mass-delete pages from a spreadsheet. Check traffic, links, leads, index status and redirect destination first. When keeping both pages, make their audience, evidence and internal-link roles clearly different.

10. Internal Linking Architecture

Measure incoming internal links to priority pages. A crawlable blog archive prevents true orphaning but does not create strong topic hierarchy.

A practical model is:

• homepage links to primary services and selected hubs;
• service pages link to relevant proof and buyer guides;
• topic hubs link to money pages and supporting articles;
• support articles link back to the relevant hub and service;
• related articles use contextual anchors rather than only auto-generated cards.

Review SEO-friendly website architecture and the internal-linking plan for implementation detail.

Check for broken links, redirected links, identical repeated anchors and priority URLs with fewer than three contextual incoming links.

11. Local SEO Review

For businesses serving named locations, verify:

• consistent business name and contact details;
• truthful service areas;
• Google Business Profile only when eligible;
• location pages with real service evidence, not swapped city names;
• locally relevant projects, logistics, FAQs or operating details;
• no fabricated addresses or reviews;
• clear link between location content and the actual service.

Pause new city pages when existing pages are thin or overlapping. Local trust is not created by repeating “best company” across dozens of places.

12. Images and Media

Check important images for:

• descriptive alternative text;
• correct intrinsic dimensions;
• responsive delivery;
• useful subject matter;
• file size appropriate to display size;
• stable layout space;
• no important text trapped only inside an image.

Prioritise the logo, LCP image, service evidence and blog covers. Decorative images can use empty alt text when they add no information.

13. Performance and Page Experience

Review field Core Web Vitals when enough Chrome UX data exists. Use Lighthouse or PageSpeed lab data to diagnose, not to promise a fixed real-user result.

Investigate:

• LCP resource discovery and render delay;
• unnecessary global JavaScript;
• oversized images;
• render-blocking CSS;
• layout shifts;
• third-party scripts;
• non-composited animation;
• mobile navigation and touch targets.

The Core Web Vitals documentation defines current metrics and thresholds. Test templates separately because the homepage, blog and demo routes can have different bottlenecks.

14. Structured Data

Validate JSON-LD syntax and page fit. Common service-site types include Organization, WebSite, Service, BreadcrumbList, Article and FAQ only when the visible content and current search guidance support them.

Schema must match the page. Do not add fake ratings, unsupported price ranges, certifications or local addresses. Google's structured data policies explain eligibility requirements; valid markup does not guarantee a rich result.

15. Lead Path and Analytics

SEO traffic has little business value if contact actions fail or lose context. Test:

• contact links preserve service or product context;
• forms validate and confirm server success;
• generate_lead fires only after confirmed submission;
• WhatsApp links use page-relevant prefilled context;
• phone and email links work on mobile;
• events appear in GA4 DebugView or Realtime;
• no personal information is sent in event parameters;
• one person owns response and status tracking.

This current VASUYASHII contact form is first-party evidence of the reviewed lead surface.

The screenshot proves the interface exists, not that every lead is delivered. Submission reliability requires endpoint and analytics testing after deployment.

16. Trust and E-E-A-T Signals

Check whether visitors can verify who operates the website and why they should trust its advice.

Review:

• About and contact details;
• named authors and editorial responsibility;
• genuine registrations shown accurately;
• real reviews with source context;
• project or product evidence;
• clear limitation and disclaimer language;
• privacy and terms pages;
• consistent organisation profiles.

Do not manufacture case studies, reviews, awards or office locations. Missing proof should become a business task, not fictional copy.

Prioritisation Matrix

30-Day Execution Sequence

Week 1: Repair crawl, status, canonical, sitemap and broken-link defects. Confirm priority money pages are reachable and indexable.

Week 2: Refresh pages with impressions, weak CTR or clear content gaps. Add truthful evidence, source citations and strong titles.

Week 3: Strengthen hubs and contextual internal links. Resolve the most obvious duplicate cluster without mass redirects.

Week 4: Test lead paths, performance and structured data. Deploy, recrawl and record a new baseline. Request indexing only for materially improved priority pages.

Common Audit Mistakes

• Treating every tool warning as equal.
• Scoring only the homepage.
• Equating sitemap submission with indexing.
• Changing canonicals before reviewing duplicates.
• Expanding content without query or buyer evidence.
• Publishing more location pages while old ones overlap.
• Reporting downloads or clicks as confirmed leads.
• Claiming rankings will improve by a fixed date.
• Fixing source metadata but not checking rendered HTML.
• Ending the audit without owners and validation steps.

FAQs

How often should a service website be audited?

Run focused checks after significant deployments and review search, content and internal links monthly. A broader audit every quarter is practical for an actively published site.

Do I need paid SEO tools?

No for the basics. Search Console, analytics, a crawler, browser tools and source inspection can reveal many issues. Paid tools help with competitor, keyword and backlink data but do not replace analysis.

Why is a sitemap URL not indexed?

A sitemap helps discovery. Google may still exclude a page because it is duplicate, low value, weakly linked, redirected, blocked or simply not selected for indexing. Inspect the final URL and Search Console evidence.

Should every page be 1,500 words?

No. The page should answer its intent completely without filler. Commercial pages may need concise clarity, while technical guides may require more depth.

Can an SEO audit guarantee ranking improvements?

No. It can identify controllable defects and opportunities. Results also depend on competition, demand, reputation, links and search-system changes.

What should the final audit deliverable contain?

A verified inventory, prioritised findings, evidence, exact fixes, owners, validation steps and a measurement baseline. Avoid a long export with no decisions.

Next Step

Start with the highest-value URLs that already receive impressions or support a lead path. Fix verified technical issues first, then improve intent, evidence and internal linking. For a scoped review, contact VASUYASHII with the priority URLs and current Search Console export.