Technical SEO Checklist: What 200 Sites Get Wrong

Technical SEO is the infrastructure that lets a search engine crawl your site, pick the right address for each page and index it. It deals with what the server says rather than with content: status codes, redirects, robots.txt, sitemaps, canonical tags and noindex. Its job is not to win rankings but to remove the obstacles in front of them.

To see how well that infrastructure is built in practice, we scanned Türkiye's 200 most popular .tr sites on 27 October 2026. The short version: 41.1 percent of the 175 sites we could load have at least one of five basic infrastructure problems (Caliency measurement, 27 October 2026). The two most common are the same site answering on two hostnames, and pages that don't exist reporting success.

We measured home-page tags in our BIST 100 study and speed in our site speed post. This post looks at the layer underneath: what the server tells Google before Google looks at the page at all.

What does technical SEO cover?

The short answer: the steps in which Google reaches a page, picks its address and indexes it. What the page says and how its title is written belong to on-page SEO; speed belongs to Core Web Vitals.

The distinction has a practical consequence. On-page mistakes usually affect one page. Technical mistakes live in a template or a server setting, so they affect the whole site at once. A server that returns 200 for every missing address does so for an unlimited number of addresses.

How we audited 200 sites

Sample: the 200 most popular domains ending in .tr among the top 100,000 sites of Tranco list 64VKX, generated on 12 October 2026 (Tranco, list 64VKX). It's the same sample we used in our site speed study.

Method: one request per check, redirects followed hop by hop, no JavaScript executed. Our client identified itself as Caliency research, connected to at most eight sites at a time and gave up after 15 seconds. The checks:

1. HTTPS: does http://domain/ reach a page that returns 200 over HTTPS, in how many hops and with which codes?
2. One hostname: do https://domain/ and https://www.domain/ end on the same host?
3. Soft 404: what does a randomly generated, non-existent address return?
4. robots.txt: is it a 200 with plain text, does it carry a Sitemap: line, does it say Disallow: / to all crawlers?
5. Sitemap: is there valid XML at the declared address or at /sitemap.xml or /sitemap_index.xml, and does it carry <lastmod>?
6. Home page: is there a noindex in meta robots or the X-Robots-Tag header, and where does the canonical point?

25 of the 200 sites didn't give us their home page. 13 refused with an HTTP error code (mostly 403), and 12 failed on DNS, TLS or the connection. The analysis covers the remaining 175 sites. Each check's denominator is the number of sites that answered that check.

What we found

The short answer: the visible work is done; the invisible work is half done (Caliency measurement, 27 October 2026):

• Of 165 sites that answered on HTTP, 153 (92.7 percent) reach HTTPS. Ten keep serving the page over plain HTTP, and one redirects in an endless loop.
• Of 168 sites where both hostnames answered, 50 (29.8 percent) serve the www and the non-www version separately, both with a 200.
• Of 173 sites that answered our test request, 37 (21.4 percent) return a 200 for a page that doesn't exist.
• 115 of 175 sites (65.7 percent) have a valid XML sitemap; 56.0 percent declare one in robots.txt.
• Only 2 sites have a noindex on the home page, and in both cases two meta tags on the same page contradict each other.

We also counted five basic problems together: HTTP that doesn't reach HTTPS, two live hostnames, soft 404s, a noindexed home page and a robots.txt closed to all crawlers. 72 of 175 sites (41.1 percent) have at least one; 27 have two or three.

Why a missing page shouldn't return 200

The short answer: because 200 means "this page exists". Google defines a soft 404 as a page telling users it doesn't exist while returning a 200 status code. Google excludes such pages from Search and reports them as soft 404s in Search Console (Google Search Central, soft 404 errors).

The same document gives the fix. If a page is gone with no replacement, return 404 or 410; if the content moved, redirect to it with a 301. A custom 404 page is a good idea, but the server should still send a 404. In Google's words, custom 404 pages are created solely for users.

In our measurement, 134 of 173 sites (77.5 percent) answered correctly with a 4xx code. Google treats every 4xx code except 429 the same way, as a signal that the content doesn't exist (Google, HTTP status codes). The 37 sites that returned 200 break down like this:

• 21 return a 200 directly; whatever address you type, a page comes back.
• 7 redirect to a 404 page, but that page returns 200. The URL says "404" while the server says "success". It's the easiest of these errors to fix.
• 5 redirect to the home page.
• 4 send you to an unrelated page: a category, a search results page or, in two cases, a news article.

Google's crawl efficiency guidance explains why this matters. Wasting server resources on unnecessary pages can reduce crawling of the pages that matter. Soft 404 pages are listed among those unnecessary URLs (Google Search Central, crawling issues). On a small site the effect is limited. On a site with thousands of product or news pages, dead addresses compete with real ones for crawling.

One site, two addresses: www and non-www

The short answer: if both hostnames return 200, you leave it to Google to decide which one to show. When a home page is reachable at addresses such as https://example.com and https://www.example.com, Google recommends choosing one and redirecting the others to it (Google Search Central, redirects).

Google's canonicalization guide ranks the signals by strength: redirects and rel="canonical" are strong signals, sitemap inclusion is a weak one (Google Search Central, specifying a canonical URL). The same guide adds an honest caveat. None of these methods is required; without a stated preference, Google picks the best version itself.

So this is not a disaster, it's a loss of control. Of the 168 sites where both hostnames answered, 118 (70.2 percent) consolidate to one. Of the 50 sites serving both with a 200, only 13 have a canonical tag on the home page (Caliency measurement, 27 October 2026). The other 37 give Google no preference at all.

20 of the 118 consolidating sites do it with a temporary redirect (302 or 307). According to Google, Googlebot follows a temporary redirect, but the indexing pipeline doesn't use it as a signal that the target should be canonical (Google Search Central, redirects).

HTTP to HTTPS: a status-code problem more than a chain problem

The short answer: the real issue isn't chain length but the redirect code used. Google's crawlers follow up to 10 redirect hops by default (Google, HTTP status codes). The longest chain we measured had 5.

Of the 153 sites that reach HTTPS, 89 get there in one hop, 54 in two and 10 in three or more. The typical two-hop chain goes to https://domain first and then to https://www.domain. That's far below the limit. Even so, Google notes that long redirect chains have a negative effect on crawling (Google Search Central, crawling issues). Going straight to the final address is cleaner.

The codes are what stand out. For 48 of 153 sites (31.4 percent), the first redirect towards HTTPS is temporary: a 302, 303 or 307 (Caliency measurement, 27 October 2026). Google uses a 301 as a strong signal and a 302 as a weak signal that the target should be processed (Google, HTTP status codes).

Let's not overstate the risk. Google already prefers HTTPS pages over equivalent HTTP pages as canonical (Google Search Central, specifying a canonical URL). A site that reaches HTTPS through a 302 is most likely indexed under its HTTPS address anyway. But announcing a permanent move as temporary is wrong information that takes one line to fix.

robots.txt and sitemaps: the file exists, the contents are wrong

The short answer: most sites have a robots.txt; nearly half lack a sitemap line in it. For 146 of 175 sites (83.4 percent), robots.txt returns a 200 with plain text. 17 have no file (404), and for 10 the address returns an HTML page (Caliency measurement, 27 October 2026).

A missing file is not a problem on its own. For any 4xx except 429, Google assumes there are no crawl restrictions. The real danger is a 5xx: if Google can't fetch robots.txt, it stops crawling the site for the first 12 hours (Google, robots.txt specification). During our scan, one site's robots.txt returned a 500; it worked again when we retried.

Only one site told all crawlers Disallow: /. A reminder: according to Google, robots.txt is not a mechanism for keeping a page out of Google; that's what noindex is for (Google Search Central, introduction to robots.txt).

The sitemap line is weaker. 98 of the 146 sites with a valid robots.txt (67.1 percent) carry a Sitemap: line. Google lists that line as one way to submit a sitemap (Google Search Central, build and submit a sitemap). For 6 of those 98, the first declared address holds no sitemap:

• One points to an internal server name that can't be reached from outside.
• One still carries a placeholder domain from a template, "senin-domainin.com" (Turkish for "your-domain.com").
• The rest return 404 or point to another domain where the TLS connection fails.

Of the 109 sites whose URL-level sitemap we could read, 72 (66.1 percent) carry <lastmod>. Google only uses that value if it is consistently and verifiably accurate. Updating a copyright date doesn't count as a significant change (Google Search Central, build and submit a sitemap).

Not every site needs a sitemap. Google says a well-linked site of about 500 pages or fewer might not need one (Google Search Central, sitemaps overview). Most sites in this sample are far larger.

noindex and canonical: rare but expensive mistakes

The short answer: a noindexed home page is almost non-existent, but both cases come from the same mistake. Two sites carry two separate meta tags on the same page, one saying noindex and the other index. Google's rule is clear: with conflicting rules, the more restrictive one applies. When robots and googlebot tags differ, the negative rules add up (Google Search Central, robots meta tag).

This kind of conflict usually comes from two layers: one tag hard-coded in the template and a second added by a plugin. If one says noindex, the other saying index saves nothing.

On canonicals, 108 of 175 home pages carry one, and 100 of them (92.6 percent) point to the page's own host. Eight point elsewhere: 4 to the other www variant, 3 to the HTTP version and 1 to another domain (Caliency measurement, 27 October 2026). Google lists an HTTPS page with a canonical to its HTTP version among the conflicts that override its HTTPS preference (Google Search Central, specifying a canonical URL).

Why do government sites do worse?

The short answer: on the checks we measured, .gov.tr sites trail .com.tr sites by a wide margin (Caliency measurement, 27 October 2026):

We didn't measure why. The same pattern repeating across so many government sites suggests shared infrastructure or a stock configuration, but that's a hypothesis. Commercial sites doing better is no surprise; for them, organic traffic is revenue.

Technical SEO checklist: 15 minutes on your own site

The list below is our measurement done by hand. A browser and the Network tab in its developer tools are enough. Read the status code from the first row of the Network tab, not from the page.

How we set priorities: blocking indexing is high, something Google can compensate for is medium, and a pure efficiency issue is low. During a migration or redesign, items 4 and 7 move up to high; we cover that in our post on when to redesign your website.

To see most of these at once, try our free SEO checker. It reports on HTTPS, redirect count, the www and non-www pair, noindex, robots.txt, sitemap and canonical. Its limit, too: it looks at a single page, doesn't run a soft 404 test and doesn't read lastmod values in the sitemap. For those two, do steps 3 and 8 by hand.

If you use Search Console, the other half of the work is there. The Page indexing report shows what Google left out and why; we explain how to read it in our post on auditing SEO without a tool.

When technical SEO isn't enough

An answer you might not expect from an SEO agency: fixing every item on this list won't win rankings on its own. Technical SEO removes obstacles; it doesn't create demand, content or trust. On a well-linked 20-page site, a missing lastmod most likely changes nothing.

In our SEO services we run the technical audit first, because content work on broken infrastructure is wasted. But our limit is clear: we can't tell you in advance how many positions or how much traffic technical fixes will bring. What we can tell you is which obstacle in front of Google has been removed. Building the infrastructure right from the start is part of the build itself; in our web development work these checks are done before handover.

What we didn't measure

• The relationship with rankings. These sites are already popular; we don't know how much traffic their infrastructure problems cost them.
• Anything beyond the home page and one made-up address. Canonical, noindex and redirect errors on inner pages are not in this data.
• JavaScript. We didn't execute it. On sites that add tags with JavaScript, what Google sees may differ, and we didn't follow meta refresh or JavaScript redirects.
• Google's own view. Some sites answer automated clients differently; 25 sites didn't give us their home page at all. The TLS errors on 5 of them may come from an incomplete certificate chain that browsers tolerate.
• Sitemaps at other addresses. We looked in three places only, so we may have missed sitemaps submitted only through Search Console or hosted elsewhere.
• Repeat runs. This was a single measurement, and transient server errors can affect results; we saw that with the robots.txt that returned a 500.

Frequently asked questions

What is technical SEO?

Technical SEO is the infrastructure that lets a search engine crawl your site, pick the right address for each page and index it. It deals with what the server says rather than with content: status codes, redirects, robots.txt, sitemaps, canonical tags and noindex. Its job is not to win rankings but to remove the technical obstacles in front of them.

What should a technical SEO checklist include?

At least six items. HTTP should reach HTTPS in one hop with a 301 or 308, and the www and non-www hostnames should resolve to one address. Missing pages should return 404 or 410, and robots.txt should load as plain text. The sitemap should be valid XML with accurate lastmod dates. Important pages should carry no noindex, and canonicals should point to the page's own address.

What is a soft 404 and how do you spot one?

A soft 404 is a page that says it can't be found, or has no real content, but is served with a 200 success code. Google excludes such pages from Search and reports them as soft 404s in Search Console. To test your own site, add a made-up path to your domain and open it. The Network tab in your browser's developer tools should show 404 or 410.

Is it a problem if both www and non-www versions load?

It isn't a disaster, but you leave the choice to Google. Google recommends picking one address when content is reachable through several and redirecting the others to it, and it treats redirects as a strong canonical signal. Without any signal, Google picks the version to show itself. In our measurement, only 13 of the 50 sites serving both hostnames had a canonical tag on the home page.

Where do popular Turkish websites go wrong on technical SEO?

Mostly in two places. Of the 175 popular .tr sites we analysed, 50 serve both the www and non-www hostname with a 200. Of the 173 that answered our test request, 37 return a 200 for a page that doesn't exist (Caliency measurement, 27 October 2026). 41.1 percent have at least one of five basic infrastructure problems, and government sites do markedly worse than commercial ones.

In short

Technical SEO is the infrastructure that lets Google reach your site, choose the right address and index your pages. On Türkiye's most popular .tr sites, the visible part is largely done. 92.7 percent of HTTP requests reach HTTPS, and 98.9 percent of home pages are indexable (Caliency measurement, 27 October 2026).

The invisible part is half done. 29.8 percent of sites serve the same content on two hostnames, and 21.4 percent report success for pages that don't exist. 41.1 percent have at least one of five basic problems. None of these errors show when you look at the page; they only show when you look at what the server says.

To see where your site stands on most of these checks, try our free SEO checker. If you'd like help prioritizing what you find, take a look at our SEO services or get in touch directly.