Technical SEO Checklist: 25 Checks for Crawl, Index & Site Health

How to use this technical SEO checklist

Do not treat technical SEO as a list of 25 equally important boxes. A blocked money page matters more than a minor structured-data warning. A site-wide 5xx problem matters more than a missing image dimension on one old article.

A useful review follows the same path a search engine has to follow: discover → crawl → render → index → serve. Work in that order. If a page fails early in the path, later optimizations cannot rescue it.

Start with a clean baseline

1. Verify Google Search Console and the correct site property

Before diagnosing anything, make sure you are looking at the right Search Console property. Confirm access to the live domain and note whether the site uses HTTPS, www or non-www, subdomains, or separate language sections.

Use the Page Indexing report for site-level patterns and URL Inspection for individual URLs. Search Console is not a crawler replacement, but it shows Google's own view of many crawl and indexing problems.

2. Run a full crawl of the live site

Use a crawler that can follow internal links and report status codes, canonicals, robots directives, page titles, headings and crawl depth. Save the crawl before making changes. That gives you a baseline to compare after the fixes.

On a WordPress site, include pages created by plugins and themes. Ecommerce stores should also review category filters, search URLs and other parameter patterns that may create large duplicate sets.

Crawlability and discovery checks

3. Check robots.txt for accidental blocks

A robots.txt file controls crawler access. It is not a reliable tool for removing an already known page from Google's index. Review every Disallow rule and make sure important pages, CSS, JavaScript and images needed for rendering are not blocked by mistake.

A common launch error is carrying a staging rule such as Disallow: / onto the live site. Check the production file after every redesign, migration or major deployment.

4. Check the XML sitemap

Your XML sitemap should point search engines toward URLs you actually want discovered and indexed. Remove obvious dead URLs, redirected URLs and pages you intentionally keep out of Search. Keep the preferred URL versions consistent with your canonical strategy.

A sitemap helps discovery; it does not guarantee crawling or indexing. Important pages should also be reachable through normal internal links.

5. Find orphan pages and weak internal paths

An orphan page has no useful internal link path from the rest of the site. Compare your crawl with the sitemap, CMS export or analytics data to find important URLs that the crawler could not reach.

Fix the architecture rather than relying on the sitemap alone. Important service, category and content pages should sit in a logical hierarchy and receive crawlable HTML links from relevant pages.

6. Make important links crawlable

Navigation and contextual links should use normal crawlable links with real destination URLs. Test menus, related-content modules and JavaScript components on the rendered page. If a user can see a navigation item but the crawler cannot follow it, discovery can break.

7. Review 4xx, 5xx and soft-404 responses

A removed URL can return 404 or 410 when that is genuinely the correct outcome. The problem is when important live URLs return errors, internal links point to dead pages, or a page returns HTTP 200 while displaying an error message. That last case can be treated as a soft 404.

Pay special attention to 5xx server errors. Repeated server failures can slow crawling, and persistent errors can eventually cause indexed URLs to drop out.

8. Flatten unnecessary redirect chains

Use a permanent redirect when a URL has permanently moved. Update internal links so they point directly to the final destination rather than passing through two or three old URLs first.

Redirect chains add avoidable requests for users and crawlers. During a redesign or migration, build the redirect map before launch and test it after deployment.

Indexability and canonical checks

9. Audit noindex directives

Export pages carrying a noindex directive and decide whether each one is intentional. Checkout steps, private account areas or internal search pages may not belong in Search. A core service page usually does.

Do not block a page in robots.txt and expect Google to see its noindex directive. Google has to crawl the URL to read a page-level noindex instruction.

10. Check canonical tags

Canonical tags help Google understand which URL you prefer when several URLs contain duplicate or very similar content. Check that important canonical pages point to the intended URL and that duplicate versions do not create circular or contradictory signals.

Google treats redirects and rel="canonical" as strong canonical signals, while sitemap inclusion is weaker. Keep those signals aligned whenever possible.

11. Review duplicate URL patterns

Look for HTTP and HTTPS duplicates, www and non-www versions, trailing-slash variants, uppercase URLs, tracking parameters, faceted filters and print or preview versions. You do not need to eliminate every parameter from the web, but the preferred indexable URL should be clear.

For ecommerce websites, filters and sorting combinations deserve special attention because they can multiply into thousands of near-duplicate URLs.

12. Check which URLs Google actually indexes

Compare the pages you expect to index with Search Console's Page Indexing report. Investigate patterns instead of chasing every excluded URL. Some exclusions are normal; others reveal a template, canonical, crawl or content problem.

If you need a deeper workflow for “Crawled - currently not indexed,” “Discovered - currently not indexed” or other URL-level problems, use our planned guide on fixing Google indexing issues. This checklist stays at the site-audit level so the two pages do not compete for the same intent.

13. Check for accidental canonical/noindex conflicts

Do not use canonical tags and noindex directives as interchangeable tools. A canonical asks Google to consolidate duplicate signals; noindex asks Google not to index the page. Review templates for cases where plugins or custom code output both unexpectedly.

Rendering and mobile checks

14. Compare mobile and desktop content

Google uses the mobile version of content for indexing and ranking. Responsive design is usually the simplest setup to maintain, but the key test is content parity: important text, links, images, robots directives and structured data should not disappear on mobile.

For a Bangladesh business site, test the real mobile layout instead of shrinking a desktop browser and calling the job finished. Check menus, forms, accordions, phone buttons, images and important content on actual phones when possible.

15. Check JavaScript-rendered content

JavaScript is not automatically an SEO problem. Google renders JavaScript. The audit question is whether important content and links are present after rendering, whether required resources can be fetched, and whether client-side errors stop the page from becoming usable.

Use URL Inspection or rendered-page testing when the source HTML and the visible page differ heavily.

16. Do not hide primary content behind required interaction

Lazy loading can be useful, but Google should not need a click, swipe or form action just to load the main content you expect to index. Test galleries, tabs, infinite-scroll areas and app-like interfaces carefully.

Architecture, URLs and security

17. Keep the site architecture understandable

Organize pages around real relationships: home → service hub → specialist service, or category → subcategory → product. Avoid deep chains created only because the CMS happened to add more folders.

A clean structure helps users navigate and makes internal linking easier to maintain. It also reduces the chance that important pages become buried or orphaned.

18. Check URL consistency

URLs should be stable, readable and predictable. Do not change them merely to insert a keyword. Every unnecessary URL change creates redirect work and another chance to break links, analytics, canonicals or sitemaps.

19. Confirm HTTPS and remove mixed-content problems

Make sure the preferred version of every important page loads over HTTPS and that HTTP versions redirect correctly. Check that images, scripts, stylesheets and other resources are not still requested insecurely.

Also check expired certificates, redirect loops and security rules that block legitimate crawlers or users.

20. Review pagination, filters and internal search where relevant

This check matters most for ecommerce, directory, news and other large sites. Decide which filtered or search-generated URLs should be crawlable and indexable. Do not let every sort order, color filter and price range become a new indexable page by default.

Performance and Core Web Vitals

21. Check Core Web Vitals with field data

Current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). The “good” thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less, measured at the 75th percentile of page visits.

Use Search Console and PageSpeed Insights to separate real-user field data from lab diagnostics. A perfect lab score is not the goal; stable, fast pages for users are.

Keep the detailed optimization work on the dedicated Core Web Vitals optimization guide and the commercial Core Web Vitals optimization service.

22. Check the main causes of slow or unstable pages

Look for oversized hero images, slow server response, render-blocking resources, excessive third-party scripts, unused plugins, long JavaScript tasks and missing image dimensions. Fix the bottleneck that the data points to instead of installing another optimization plugin blindly.

For WordPress, test after plugin, theme and builder updates. A technically healthy page can become slow after one new widget or tracking script.

Structured data and search appearance

23. Validate structured data that matches visible content

Structured data can help Google understand page entities and can make eligible pages available for supported search features. Use markup that accurately describes the visible page. Validate the code with Google's Rich Results Test when the type is supported.

Because Rank Math is already installed on SEO Agency BD, avoid duplicating schema in a Custom HTML block. For specialist implementation work, keep that commercial intent with the schema markup service.

Language, deployment and monitoring

24. Check multilingual signals only when the site needs them

If a website has separate equivalent English and Bangla URLs, review language relationships, canonicals and internal links as one system. Do not add hreflang merely because a page contains some Bangla words or because the business serves Bangladesh.

Each language URL should stand on its own, remain crawlable, and point users to the correct equivalent page where one exists.

25. Re-crawl after every important fix or release

A fix is not finished when the developer says it is deployed. Re-crawl the affected templates, inspect important URLs, watch Search Console, and test the mobile page again. Compare the new crawl with your baseline.

Repeat the lighter version of this checklist after a redesign, domain or CMS migration, major template change, large plugin update, URL restructure or sudden indexing drop. For a full diagnosis beyond the technical layer, use the complete SEO audit. For implementation of broad crawl, index and architecture fixes, the commercial owner is our technical SEO optimization service.

Technical SEO priorities for Bangladesh business websites

The checklist is universal, but the implementation depends on the site. A five-page service business does not need the same crawl strategy as a marketplace with hundreds of thousands of filter URLs.

WordPress service website

Check plugin-generated archives, attachment URLs, staging noindex settings, sitemap output, canonical tags, broken internal links and page-builder performance. Test important enquiry and phone actions on mobile after theme or plugin changes.

WooCommerce or ecommerce site

Spend more time on filters, pagination, product availability, category architecture, duplicate parameters, schema and performance. A product catalog can create technical duplication much faster than a small brochure site.

English and Bangla content site

Decide whether languages have separate URLs. Keep each version crawlable and internally linked. Check that mobile pages retain the same important content and metadata as desktop.

A compact technical SEO audit sheet