SMEPlan

Technical SEO Audit Checklist for a 2-3 Day Turnaround

Đăng ngày: 28.06.2026 | Tác giả: Phan Giang
Mục lục bài viết9 mục

Use this workflow to ship a client-ready technical SEO audit in 2-3 days using only GSC, GA, and a crawler. By the end of day two, you will have a prioritized issue list with reproducible evidence and a one-page executive summary your client can approve in a 30-minute review.

Prerequisites before you start:

  • Access to Google Search Console and Google Analytics
  • A reliable crawler: Screaming Frog or Sitebulb
  • Permission to crawl production and a working sitemap URL
  • 2-3 days of focused time
  • Baseline organic traffic and top landing-page metrics exported
  • Server logs are optional but useful if available

Define scope, risks, and success baseline

Before you open a single tool, get crisp on what is in scope, what could break, and what success looks like. Skipping this step is the most common reason audits stall at the presentation stage – the client asks “did you check our subdomain?” and you have no answer.

Confirm scope and constraints in writing:

  1. Domains and subdomains to include or exclude
  2. Environments: production only, no staging or dev
  3. Locales and URL parameters in play: language variants, country codes, sort and filter parameters
  4. CMS and deployment cadence: who can ship what change and how quickly
  5. Any known incidents in the past 90 days: migrations, redesigns, manual actions, traffic drops

Capture a success baseline immediately:

Pull these before anything else changes:

  • GA: last 28 days vs. prior 28 days for sessions, conversions, top organic landing pages, and device split. Export the top 100 organic landing pages with sessions and conversions attached.
  • GSC: last 28 days for total clicks, impressions, average position, and CTR. Export Performance by page and by query for the top 200 pages.

Note the critical templates and pages you must protect throughout the audit: home, category, product, blog hub, signup, and checkout. If any of these move during your audit window, you need to know immediately.

Define risk guardrails before touching anything:

  • No sitewide robots.txt edits without a dry-run in a sandbox file validated through the GSC robots tester
  • No sitewide meta robots changes without template-level testing on 1-2 low-traffic paths first
  • No redirect rules shipped without running a loop and chain test

Two-day technical audit checklist (printable)

Use this as your daily task board. Each block maps to a section below.

Day 1 AM

  • Align scope and risks with the stakeholder by email or a 15-minute call
  • Pull GA and GSC baselines and exports
  • Configure crawler seeds from the sitemap and GSC top pages

Day 1 PM

  • Run initial crawl for coverage
  • Triage critical blockers: robots, noindex, indexation failures
  • Start the evidence log with URLs and screenshots for every blocker found

Day 2 AM

  • Deep-dive redirects, canonicals, and duplicate clusters
  • Verify rendering and JS SEO on key templates
  • Review sitemaps, internal links, and crawl efficiency
  • Assess Core Web Vitals and site hygiene

Day 2 PM

  • Score all issues by impact and effort
  • Draft the executive summary one-pager
  • Assemble deliverables: findings, evidence log, prioritized fix list
  • Run the 30-minute client review and confirm next steps

Configure data sources and fast, accurate crawl

A crawl that is fast but misconfigured wastes a full day of your audit window. Get this right once and save the output file – you will need to rerun it if scope changes.

Screaming Frog configuration for speed and accuracy:

  1. Seeds: use sitemap URLs plus the top 200 pages from your GSC Performance export. This forces coverage of the templates that actually drive traffic rather than crawling from the home page outward and missing deep sections.
  2. User-Agent: Googlebot Smartphone. This mirrors what Google actually sends.
  3. Obey robots.txt: enabled. You are auditing what Google sees, not bypassing it.
  4. Crawl speed: 1-2 URLs per second on production. Going faster risks triggering rate limits or skewing server performance data.
  5. Max URLs: set an upper bound for the day 1 scan, for example 50,000 URLs, so the crawl completes within your window.

Ensure the right data is captured:

  • Rendering: enable JavaScript rendering only for a targeted sample of JS-heavy templates, not the full site. Full-site JS rendering is slow and can overload a production server.
  • Canonicals: extract both rel=canonical and HTTP header canonicals. Missing the header variant is a common gap.
  • Indexability: extract meta robots and X-Robots-Tag headers together, not just one or the other.
  • Status codes: include response times and full redirect chains.
  • Hreflang: enable extraction if the site has language or country variants.
  • Custom extraction: create finders for “noindex”, “canonical”, “og:url”, and key parameter patterns such as “?sort=”, “?color=”, “?utm_”. These are the patterns most likely to create unintended URL variants.
  • API enrichment: connect GA and GSC in Configuration – API Access to attach clicks, impressions, and sessions directly to crawled URLs. Without this, you will sort issues by count rather than by traffic impact and risk misprioritizing.

Save and document your configuration:

Save the crawl config file and the crawl output. Note the start time, the seeds used, and your rendering choices in the evidence log. If the client asks you to re-run the audit in three months, you need to reproduce identical conditions.

Common pitfalls:

  • Crawling the full site with JS rendering enabled burns time and may overload a production server. Render only the templates where you have a specific reason to suspect a JS issue.
  • Skipping API enrichment means your priority list is based on URL counts, not traffic impact. A noindex bug on a low-traffic template looks the same as one on a template driving 40% of organic sessions – until you add traffic data.

Check access and indexation blockers first

If Google cannot access or index a page, nothing else on that page matters. Front-load these checks before touching redirects, canonicals, or Core Web Vitals.

robots.txt access control:

  1. Open GSC – Settings – Crawl stats and the robots.txt tester. Confirm the file is reachable and returns a 200.
  2. Scan for Disallow: /, directives blocking key paths such as /category/ or /product/, or wildcard rules you cannot explain.
  3. If a change is needed, propose the new directive in a sandbox robots file and validate it in the GSC tester before touching production.

Meta robots and X-Robots-Tag:

  1. Pull the crawler report for all URLs returning noindex, nofollow, or nosnippet directives.
  2. Check HTTP response headers for X-Robots-Tag: noindex, which applies to non-HTML resources like PDFs.
  3. Cross-reference with GSC Pages report: look for “Excluded by ‘noindex’ tag” and “Blocked by robots.txt” counts and match them to your crawler data.

Indexation health in GSC:

  1. Open the Pages report and focus on the Not Indexed buckets with high URL counts.
  2. Investigate these three in order of typical severity: “Duplicate without user-selected canonical”, “Crawled – currently not indexed”, “Soft 404”.
  3. Use URL Inspection – Live Test on 3-5 representative URLs in each failing bucket to confirm what Google is actually seeing.

Quick visibility sanity checks:

  • Run site:example.com for your top branded queries. If the home page or key category pages are missing, you have a suppression issue to escalate immediately.
  • Confirm the top 10 organic landing pages from your GA export are visible in the site: results.

Fix patterns – safe proposals only:

  • Remove accidental noindex from indexable templates by adjusting the template-level condition, not the individual URL.
  • Unblock critical paths in robots.txt by removing or narrowing the offending directive, validated in the GSC tester first.
  • Keep noindex intentionally on low-value duplicates and zero-stock pages.

Evidence log template – copy and use for each finding:

Issue ID:
URL:
Finding:
Evidence source and how to reproduce:
Screenshot filename:
Suggested fix:
Owner and next step:

Filled example – indexation blocker:

Issue ID: IDX-001
URL: https://www.example.com/category/shoes/
Finding: Page returns 200 but carries meta robots noindex.
Evidence source and how to reproduce: View-source confirms <meta name="robots" content="noindex">. GSC Pages report shows this URL under "Excluded by 'noindex' tag". Reproducible by crawling /category/* and filtering the meta robots column for "noindex".
Screenshot filename: IDX-001-noindex-category-shoes.png
Suggested fix: Remove noindex from the category template where product count > 0. Retain noindex for zero-product categories to avoid soft 404 signals.
Owner and next step: SEO to confirm template condition logic. Dev to adjust meta robots output in the category template.

Filled example – robots.txt block:

Issue ID: BOT-001
URL: https://www.example.com/product/
Finding: /product/ path is disallowed in robots.txt. GSC Crawl Stats shows 0 crawl requests to /product/* in the past 28 days.
Evidence source and how to reproduce: robots.txt line 14: Disallow: /product/. GSC robots.txt tester confirms blocked for Googlebot. Crawl confirms zero /product/ URLs indexed in GSC Pages.
Screenshot filename: BOT-001-product-disallowed.png
Suggested fix: Remove or narrow the Disallow directive to exclude only the /product/internal-admin/ subpath, not the full /product/ tree. Validate in sandbox robots file before deploying.
Owner and next step: Dev to adjust robots.txt. SEO to validate in GSC tester and monitor crawl stats for 48 hours after deploy.

Early warning signs you are missing a blocker:

  • A high count of “Crawled – currently not indexed” on pages that have strong internal links and existing backlinks – this pattern often points to a thin content or soft 404 signal, not a crawl issue.
  • Home or key category pages are absent from site: queries.
  • GA organic landings collapse on a specific template immediately after a deploy, particularly a deploy that touched robots.txt or meta robots logic.

Audit redirects, canonicals, and duplicate control

Redirects and canonicals decide which URL Google treats as the authoritative version. Misconfigurations here quietly drain link equity and send mixed signals over months.

Redirects:

  1. Export all redirect chains from the crawler. Flag any chain longer than one hop – every additional hop wastes crawl budget and dilutes equity.
  2. Verify HTTPS enforcement and canonical host: confirm that non-www redirects to www (or the reverse) consistently with a single 301. Mixed behavior on subpaths is common and easy to miss.
  3. Audit for 302s on permanent routes. A 302 signals a temporary move – Google does not pass full equity through it and may not update its index. Legacy 302s from A/B tests or CDN configs are a frequent culprit.
  4. Normalize trailing slash, uppercase characters, and URL encoding to one canonical form sitewide.
  5. Confirm that marketing parameters like ?utm_source= do not create indexable URL variants that split equity.

Canonicals:

  1. Every indexable page should carry a self-referential canonical. Pull the crawler report and flag any indexable page with a missing or cross-domain canonical that cannot be explained.
  2. Canonicalized pages must be duplicates or clearly inferior variants. If a page with unique content is canonicalized to a different URL, Google may ignore both.
  3. Avoid pairing noindex with a canonical pointing to a different URL on pages you want to rank. The signals conflict and Google’s behavior in this case is inconsistent.
  4. For paginated series, set canonicals to the first page or the full-content page, depending on site architecture – not to a paginated variant.

Duplicate detection:

  1. Use the crawler’s Near Duplicates or content hash report to identify high-similarity URL clusters.
  2. Focus on facets and sort parameters that generate large URL spaces: /shoes/?color=black, /shoes/?color=blue, and so on. These are rarely unique enough to index.
  3. Prioritize duplicates that have traffic attached. A duplicate cluster with zero sessions can wait; one where two URLs are splitting the same rankings needs immediate consolidation.

Common pitfalls:

  • Relying on canonicals alone to suppress parameter-generated duplicates when the parameter space is large. Canonicals are a hint, not a directive. For infinite facet spaces, use robots.txt Disallow or parameter handling at the application level.
  • Leaving 302s on core navigation routes. Beyond the equity concern, some CDN configurations silently rewrite 301s to 302s after a config update – worth checking with the dev team.

Verify rendering, resources, and JavaScript SEO

If primary content, internal links, or canonical tags are injected client-side, Google may not see them consistently. Rendering budget is finite – Google does not execute every JavaScript path on every crawl.

Steps:

  1. Select a sample of 5-10 URLs from each key traffic-driving template where JavaScript is involved in rendering the primary content or navigation.
  2. Enable JavaScript rendering in Screaming Frog for this sample only – not the full crawl.
  3. Compare raw HTML against rendered HTML for each sampled URL. Confirm that the primary body content, canonical tag, meta robots, and internal links are all present in the rendered output. If any are missing, they are invisible to Google.
  4. Check for blocked resources: any JS, CSS, or XHR call blocked by robots.txt or CORS will prevent Google from fully rendering the page.
  5. Use GSC URL Inspection – View Crawled Page – HTML and Screenshot to see what Google actually captured on its last crawl of representative URLs. Compare this against what you expect to be there.
  6. Confirm that URLs required for discovery are reachable via standard anchor links, not JavaScript click handlers, form submissions, or infinite scroll without URL updates.

Fix patterns:

  • Server-side render or pre-render the canonical tag, meta robots, and primary navigation links on key templates. These must be present in raw HTML.
  • Never inject or modify the canonical or meta robots tags client-side. If these values are set in JavaScript, Google may use an earlier or empty value.
  • Replace JavaScript click handlers used for internal navigation with proper <a href> anchor links.

Common pitfalls:

  • Assuming Google executes all JavaScript rendering paths. In practice, Google’s rendering queue means some pages are crawled without full rendering, particularly deep or infrequently linked pages.
  • Content hidden behind a user interaction such as a tab expansion or “load more” button. Google sees the collapsed state. If that content includes internal links or body text you want indexed, it needs to be in the raw HTML or rendered output without requiring interaction.

A clean sitemap and a well-linked architecture help Google find and prioritize what matters. Crawl budget misuse is a slow-burn problem – it compounds over months as new pages are added.

Sitemaps:

  1. Confirm your sitemap contains only URLs that return 200, are canonicalized to themselves, and are set to index. Any 3xx, 4xx, or non-canonical URL in the sitemap sends a conflicting signal.
  2. Keep each sitemap file under 50,000 URLs or 50 MB. Use a sitemap index file to reference multiple sitemaps if the site exceeds this.
  3. Use meaningful lastmod values on large sites to help Google prioritize recrawl. A lastmod set to today’s date on pages that have not changed is worse than no lastmod.
  4. For multilingual sites, confirm hreflang annotations are consistent in the sitemap or on-page, not split between both.

Internal links:

  1. Run the crawler Depth and Orphaned URLs reports with GA and GSC data attached. Pages that are orphaned but still receive paid or email traffic lose crawl discovery and any equity from links you build later.
  2. Ensure critical templates – home, category, product, blog hub – are reachable within three clicks from the home page. Pages buried deeper are crawled less frequently.
  3. Add hub pages or footer links for high-value sections that currently sit too deep. This is a low-effort, high-impact fix.
  4. Use descriptive anchor text. A site where every internal link reads “read more” or “click here” loses the topical signal that helps Google understand what the linked page is about.

Crawl efficiency:

  1. Disallow URL patterns that generate infinite parameter spaces and do not create unique indexable value: sort parameters, session IDs, print versions.
  2. Handle parameter normalization at the application level where possible – rewriting parameters to a canonical form before they reach the server avoids the issue entirely.
  3. Note: nofollow on internal links is not a crawl control mechanism. Google can still crawl a nofollowed URL. Use robots.txt Disallow or canonical strategies to manage crawl budget on parameterized paths.

Common pitfalls:

  • Pointing your sitemap at non-canonical URLs. If a sitemap entry and its on-page canonical disagree, Google has to decide which signal to trust. It usually follows the canonical, making the sitemap entry useless – and a source of confusion in your GSC data.
  • Orphaning pages that still receive paid or email traffic. These pages continue generating sessions but gradually lose organic visibility as crawl frequency drops.

Assess Core Web Vitals, mobile, site hygiene

Core Web Vitals affect ranking. Site hygiene issues like 4xx errors and mixed content can quietly undermine trust signals. Focus on field data and template-level fixes, not individual URL tweaks.

Core Web Vitals:

  1. Open the GSC Core Web Vitals report and identify failing templates on mobile and desktop separately. Mobile and desktop can fail for different reasons.
  2. For each failing template, pull a representative URL into PageSpeed Insights. Focus on the field data section – CrUX data – not the lab score.
  3. Prioritize template-level improvements that fix many pages at once:
    • LCP (Largest Contentful Paint): typically caused by large unoptimized hero images. Compress, use modern formats (WebP/AVIF), and add fetchpriority="high" on the LCP element.
    • CLS (Cumulative Layout Shift): typically caused by images without declared dimensions, late-loading banners, or web fonts causing FOIT. Set explicit width and height on image elements.
    • INP (Interaction to Next Paint): typically caused by heavy JavaScript executing on the main thread during user interaction. Defer non-critical scripts.

Mobile and usability:

  1. Confirm mobile viewport meta tag is present and correct on all templates.
  2. Check tap target sizes on mobile – buttons and links should be at least 48x48px with adequate spacing.
  3. Flag intrusive interstitials or popups that shift content or block the main view on load. These are a ranking signal and a user experience issue.

Site hygiene:

  1. Export the full 4xx and 5xx URL list from the crawler. Prioritize 4xx URLs that still receive internal links or have external backlinks – these are equity sinks.
  2. Fix mixed content: any page loaded over HTTPS that references HTTP resources generates a browser warning and may trigger security flags.
  3. Check that HTTPS is enforced consistently across all subdomains in scope. A subdomain returning HTTP without a redirect is a separate risk.

Common pitfalls:

  • Spending the majority of audit time on lab metrics from PageSpeed Insights. A perfect lab score on a page that fails in field data does nothing for rankings. Always anchor to CrUX field data from GSC.
  • Tweaking individual URLs when the issue is a template-level asset, layout rule, or JavaScript file. One template fix can resolve hundreds of failing URLs simultaneously.

Prioritize, package fixes, present client deliverables

The audit is only complete when the client understands the findings, trusts the evidence, and has a clear path to act. This section is where most SEO audits lose trust – by presenting a technically correct but unactionable list.

Impact x effort scoring – template:

FieldScale
Impact1 = negligible (page-level), 5 = sitewide ranking or session impact
Effort1 = config or copy change, 5 = multi-sprint dev and QA

Priority rule: sort by highest Impact first, then lowest Effort. Break ties by risk and reversibility – a high-impact, low-effort fix that is also easily reversible is always P1.

Filled examples:

Issue: Accidental noindex on category template
Evidence: GSC Pages report shows 312 URLs excluded by noindex. Crawler confirms meta robots noindex on all /category/* URLs.
Impact: 5
Effort: 2
Risk and reversibility: Low - single template flag change, reversible with a feature toggle.
Priority: P1

Issue: Redirect chains on top product URLs
Evidence: Crawler shows /p/123 -> /product/123 -> /product/123/ as two 301 hops. GA shows 18% of organic landings arrive at the first hop URL /p/123.
Impact: 4
Effort: 2
Risk and reversibility: Low - update rewrite rules to resolve in one hop. Validate with redirect tester before deploying.
Priority: P1

Issue: Sitemap contains 14% non-canonical URLs
Evidence: Crawler-to-sitemap join shows 3xx URLs and parameterized variants in sitemap index.
Impact: 3
Effort: 1
Risk and reversibility: Low - regenerate sitemap from canonical URL set only.
Priority: P2

Evidence to attach for every finding:

  • URL list or URL pattern and the number of affected pages
  • GSC report screenshot showing the issue
  • Crawler export snippet confirming the finding
  • Exact reproduction steps: what to open, what filter to apply, what to look for
  • Proposed fix in plain language, the owner, and a rollback plan for P1 items

Executive summary one-pager for stakeholders:

This one page is what gets the audit approved. Write it last, after you know the full scope of findings. Every sentence should translate a technical finding into a business outcome.

Title: Technical SEO audit – [Site name] – [Date]

What we found and why it matters

Some of your top pages are telling Google not to list them in search results. Others make Google and your visitors take extra steps to reach the final page address. Both reduce how often you appear in search and how quickly pages load.

What we recommend fixing now

  • Remove the “do not list” instruction from live category pages while keeping it on empty or low-value pages
  • Collapse multi-step redirects on top product URLs into a single direct step
  • Regenerate the sitemap so it only lists final, indexable page addresses

What this means for your business

  • Category pages return to normal search visibility within days of Google recrawling
  • Users and Google reach product pages faster, with no extra steps
  • Google receives a clean map of the site with no conflicting signals

What is safe to change and what is not

All three P1 recommendations are configuration changes. Each can be reversed within hours if unexpected issues appear in analytics. No database or content changes are required.

Who does what and when

ActionOwnerDeadline
Confirm template noindex ruleSEOToday
Remove noindex flag from category templateDevTomorrow
Collapse redirect chains on /p/* URLsDevTomorrow
Regenerate sitemapDev or SEODay 3
Monitor GA organic landings and GSC errorsSEO48 hours post-deploy

Filled executive summary snippet:

Category pages at https://www.example.com/category/* carry a “do not list” instruction that tells Google to exclude them from search results. These pages account for 42% of organic sessions over the past 28 days. While this instruction is active, Google will not show them, which directly reduces visits and the revenue attached to those visits. Removing this instruction from live categories – while keeping it on empty categories to avoid thin-content signals – is a one-line template change the dev team can ship and reverse within the same day.

30-minute presentation structure:

  • 5 minutes: context and baseline – one chart showing clicks, sessions, and top landing templates over the past 28 days
  • 10 minutes: top 3 issues – one slide each with the finding in plain business language, one evidence screenshot, and the recommended fix
  • 10 minutes: prioritized plan – the impact x effort list with owners and timelines
  • 5 minutes: risk guardrails, confirm decisions, and next steps

During the review, get two verbal confirmations: (1) that the scope and timelines are feasible, and (2) who will implement each P1 within the week. Follow up with a recap email listing owners and dates within the hour.

When FL2 is at risk:

  • The stakeholder keeps asking for definitions rather than discussing owners and timelines – this means the one-pager still has unexplained jargon. Add plain-language glosses to any technical term and resend.
  • Engineering requests scope cuts due to capacity – this is the moment to use your P2 list. Offer a reduced scope that still addresses the highest-impact items.
  • After a fix deploys, GSC shows a new spike in “Blocked by robots.txt” or GA organic landings drop on previously protected templates – roll back the change immediately using the documented rollback plan and investigate before redeploying.

When the audit is complete but approval stalls:

A thorough audit that stays technical throughout will not get approved by a non-technical decision-maker. If the one-pager still uses terms like “noindex”, “canonical”, or “crawl budget” without a plain-language explanation alongside each, the client may hesitate even if every finding is correct. The test is simple: hand the one-pager to someone outside SEO and ask them to explain the top recommendation back to you. If they cannot, rewrite that section before the review.

Deliverable checklist – send with the review:

  • Executive summary one-pager
  • Issues list with impact x effort scores and priorities
  • Evidence log with URLs, screenshots, and reproduction steps for each finding
  • Crawler exports: all URLs, indexability, canonicals, redirects, and sitemap join
  • One implementation brief per P1 issue: what to change, the owner, and the rollback procedure

With this checklist, you can complete a professional, prioritized technical audit in 2-3 days using only GSC, GA, and a crawler. The key is sequencing: indexation blockers before redirects, redirects before rendering, field data before lab scores. Package every finding with evidence your engineering team can reproduce and language your client can act on without a follow-up call.

Hệ thống liên kết hữu ích tại SMEPlan

Bài viết liên quan cùng chủ đề

The complete 2026 SEO guide: every criterion that still matters, and what actually changed

Full-Funnel Digital Marketing Framework: A Blueprint for Marketing Leaders

Search intent mapping SEO: SERP-first defensible framework