Technical SEO Checklist: The Complete Item-by-Item Guide

This technical SEO checklist gathers, in order, the items you should check so that your site can be found and crawled by search engines, the right pages get indexed, and visitors get a fast, secure experience. Even the best content cannot rank if it cannot be crawled or has been accidentally excluded from the index; that is why it is necessary to check the foundation before content work. We wrote each item so you can mark it "yes / no".

Why does technical SEO come first?

A search engine works in three stages: crawling (finding and downloading the page), indexing (understanding and storing the content) and ranking. Technical SEO ensures the first two stages run smoothly. If a problem occurs here, the later stages never start. Before you begin, make sure Search Console is installed; for setup, see our Search Console getting started guide. Most of the checks below are verified with the reports there.

Three free sources are enough to speed up the check: Search Console (how Google sees you), PageSpeed Insights (speed and Core Web Vitals) and a desktop crawling tool (which goes around your site like a search engine and lists broken links, redirects and missing tags). Mark the result of each item as "OK / to fix / none" and keep it in a dated table; after three months you can compare against the same table.

1. Crawl checks

• Important pages are not blocked by robots.txt. The "URL Inspection" tool in Search Console shows whether a page can be crawled.
• Pages return HTTP 200. Important pages must not return 404, 500 or a soft 404 (a page that returns 200 but has no real content).
• Redirects are single-step and 301. Chained redirects (A → B → C) should be shortened; use 302 only for temporary situations.
• Important pages are connected with internal links. Orphan pages that receive no link from anywhere can be missed. For details, see our internal linking strategy article.
• Broken internal links are cleaned up. Fix or remove links that return 404.
• URL structure is clean. Prefer short, readable, lowercase addresses without unnecessary parameters; do not generate hundreds of parameter variations pointing to the same content.
• No Googlebot errors in server logs. On large sites, frequent 5xx responses to bot requests reduce crawling.

2. Indexing checks

• The Pages report in Search Console has been reviewed. Read each "not indexed" reason one by one (e.g. "Crawled - currently not indexed", "Alternate page with proper canonical tag", "Excluded by noindex tag").
• No noindex on important pages. A <meta name="robots" content="noindex"> added during development and then forgotten is a common mistake.
• Unnecessary pages are deliberately excluded. Consider noindex for thank-you, cart, filter and internal search pages.
• Thin content has been reviewed. Merge or improve pages that are a few sentences long and repetitive.
• A site search has been done. Type site:yourdomain.com into Google and roughly compare the number of indexed pages with your real count.

3. Canonicals and duplicate content

The canonical tag (<link rel="canonical" href="...">) is the way to say "this is the main version" when the same or very similar content exists at more than one address.

• Each page declares itself as canonical (self-referencing) or deliberately points to the main version.
• The canonical uses an absolute address (https://...) and does not point to a redirect or a 404 address.
• www / non-www, http / https and trailing-slash variations are redirected with 301 to a single version.
• Filter and sorting parameters give a canonical to the main category page.
• Canonical and noindex are not used together. The two signals contradict each other.

A typical example of canonical errors: in an e-commerce site, a category address with a "?sort=price" parameter declares itself as canonical. As a result, the same product list gets indexed at dozens of addresses and the pages compete with each other. The fix is to give all parameter variations a canonical pointing to the clean category address.

4. Hreflang and multilingual structure

If you have pages for more than one language or region, hreflang tells Google which version to show to which user.

• Each language version lists the others (mutual confirmation). If page A points to B, B should also point to A.
• It includes its own language version (self-reference).
• Language and region codes are correct: tr, en, en-gb; often tr is enough instead of tr-tr.
• Target addresses return 200 and do not conflict with the canonical.
• x-default is defined: for the language selector or default page.
• Every language is actually translated. Do not mark untranslated pages as a different language.

5. Sitemap and robots.txt

A critical distinction: robots.txt blocks crawling but does not remove from the index. If you want a page not to appear in the index, use noindex and do not block it with robots.txt at the same time; otherwise Google cannot see the noindex tag at all.

6. Speed, mobile and security

• Core Web Vitals have been checked. Aim for LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. For details see our Core Web Vitals guide; for measurement you can use PageSpeed Insights.
• Images are compressed (WebP/AVIF), have defined dimensions, and below-the-fold images are lazy-loaded.
• Server response time (TTFB) is short and caching is enabled.
• Mobile friendliness: Responsive design, viewport tag, enough space between tappable elements, and the same content on mobile as on desktop.
• The whole site is HTTPS. The certificate is valid, there is no mixed content, and http addresses are redirected to https with 301.
• Security headers and up-to-date infrastructure: Current PHP/CMS version and malware scanning.
• Basic on-page tags are in order: A unique title and description on each page, and a single H1. For writing tips, see our meta title and description guide.

7. Structured data

Structured data (schema.org markup) describes what a page is in a way machines understand, and makes it eligible for rich results (stars, FAQs, prices, recipes, etc.). Google recommends JSON-LD as the format.

• Suitable types are applied: Organization for corporate sites, Article for articles, Product for products, LocalBusiness for local businesses, and BreadcrumbList to show the path.
• The markup matches the visible content exactly. Adding invisible or fake information carries a manual action risk.
• Validation is done: Google's Rich Results Test and the "Enhancements" report in Search Console show errors and warnings.
• Current requirements have been checked: Which types produce rich results changes over time; follow the current list on Google Search Central.

Content generated by JavaScript

On sites built with frameworks such as React or Vue, content is generated in the browser. Google can run JavaScript, but this happens in a second queue, can be delayed and can produce errors.

• Is the important content present in the first HTML response? Compare what Google sees using "URL Inspection → Test live URL → View crawled page" in Search Console.
• Are the links real <a href> elements? Buttons that navigate only through click events may not be crawled.
• Are the title, description and canonical written on the server side? Where possible, use server-side rendering (SSR) or pre-rendering.
• Are there pagination links instead of infinite scroll? Otherwise deep content may never be discovered.

Common problems and fixes

How often should you check?

Conclusion

The purpose of technical SEO is to remove the obstacles in front of your content: your pages should be crawled, indexed with the correct address, load fast and be labelled clearly. Transferring the seven headings above into a spreadsheet and crawling your site step by step will produce a solid table in half a day. Once the problems are fixed, the turn comes for content and visibility work; for that you can follow our organic traffic growth methods article.

Once you are sure your site is technically ready, you can also look at the organic hit approach to support your visibility in search results. Rankings are still decided by Google's algorithms; HitBot does not replace these decisions, it is only a tool alongside the work you carry out.