WHAT IS TECHNİCAL SEO AND HOW TO DO IT

Technical SEO is the infrastructure work that lets Google crawl, index and serve your site, regardless of how good your content is. Even the strongest content stays invisible if it is technically inaccessible. Drawing on official Google documentation, we cover the crawl-index-serve process, foundations like robots.txt and sitemaps, Core Web Vitals and mobile-first indexing, and a practical audit checklist, without hype. Technical SEO is the ground on which strong SEO and AEO work is built.

What Is Technical SEO and How Does It Differ From On-Page SEO?

Technical SEO deals with the site's infrastructure: robots.txt, sitemaps, canonicalization, page speed, mobile parity and rendering. On-page SEO deals with the content itself, such as headings, text quality, relevance and internal-link context. Technical SEO makes content discoverable and processable; ranking is decided not by technical settings alone but together with content quality. There is an important Google caveat: indexing is not guaranteed. Not every processed page is indexed, and not every indexed page is served. For small and medium Turkish sites, technical foundations like accessibility, speed and mobile parity often provide high leverage.

How Google Search Works: Crawling, Indexing, Serving

The process Google documents has three stages. In crawling, Googlebot visits known pages, new addresses discovered from links, and sitemap URLs; it reliably extracts a link only if it is an HTML anchor element with an href attribute, and it mostly does not follow buttons driven by JavaScript. In rendering, Googlebot processes the page with a current version of Chrome and executes JavaScript. In indexing, content and tags are analyzed, similar pages are clustered, and a canonical address is chosen. In serving, ranking is done programmatically based on hundreds of factors including the user's location, language and device. One technical detail: Googlebot fetches the first 2 MB of supported files and the first 64 MB of PDFs, so place critical meta and structured data early in the page.

Crawlability: robots.txt, Crawl Budget and HTTP Codes

robots.txt tells crawlers which files they may or may not request; that is, it only controls crawling and does not block indexing. Google generally caches this file for up to 24 hours and does not process the crawl-delay directive. Crawl budget has two components: crawl capacity, which depends on your server's response speed, and crawl demand, which depends on popularity and freshness. Google says only very large sites need to worry about crawl budget; the rough classification thresholds are more than a million pages changing weekly or more than ten thousand pages changing daily, and Google notes these are rough estimates, not exact thresholds. HTTP status codes matter too: 404 or 410 is the correct signal for removed pages, 5xx server errors slow crawling, and redirect chains should be avoided.

Indexability: noindex and Canonical

To keep a page out of search results, use the noindex robots meta tag or an X-Robots-Tag HTTP header. Watch a critical trap: if you block a noindexed page with robots.txt, Googlebot never sees the noindex directive and the page can still appear in results via external links. Canonicalization is Google clustering similar pages and selecting the address that best represents the group. Place the rel=canonical tag only in the head, specify a single canonical per page, and avoid conflicting methods; a self-referencing canonical is usually a good default. In paginated series, pointing page two to page one causes the later pages not to be indexed, so avoid it.

XML Sitemaps: When Are They Needed?

A sitemap helps discovery of new or updated pages, but it does not guarantee crawling or indexing. It is not mandatory for well-internally-linked sites of roughly 500 pages or fewer; it is recommended for large sites, rich media and Google News content. The official limits are 50 MB or 50,000 URLs per sitemap; larger than that, the file is split into a sitemap index file. The file must be UTF-8 encoded and contain only fully qualified, canonical URLs. Google ignores priority and changefreq values and considers lastmod only when it is consistent and accurate. Contrary to a common misconception, submitting a sitemap does not guarantee indexing; it only helps discovery.

Core Web Vitals and Page Speed

Core Web Vitals measure real-user experience with three metrics: LCP (loading), INP (responsiveness) and CLS (visual stability). The good thresholds on web.dev are: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less. CLS is a unitless ratio, not a time. INP replaced FID as an official Core Web Vital on March 12, 2024, and FID support ended on September 9, 2024; because INP measures the responsiveness of all interactions, it is harder to pass on most pages. Google measures these at the 75th percentile, segmented across mobile and desktop, using real-user (CrUX) data; a page passes when at least 75 percent of views meet the good threshold. Because thresholds can be revised over time, always confirm current values on web.dev.

Page Experience, Mobile-First Indexing and HTTPS

Page experience is not a single ranking signal; Google clearly says there is no single signal and suggests six self-assessment questions: good Core Web Vitals, HTTPS, good display on mobile, low intrusive-ad density, avoiding interstitials, and distinguishable main content. Mobile-first indexing is complete; Google now uses the mobile version of the site for indexing and ranking. Content parity is therefore critical: text, meta tags, structured data and headings that exist on desktop but are hidden on mobile may not be indexed, so the same primary content must exist on both. HTTPS has been a confirmed signal since the August 2014 announcement, but Google called it very lightweight there and said it affected fewer than 1 percent of queries; today HTTPS is not a competitive advantage but a baseline hygiene requirement whose absence is a negative.

Site Architecture and Internal Linking

Every page should be reachable through a crawlable HTML link from at least one other page; orphan pages with no incoming links may not be discovered. A logical URL structure and clear internal links to important pages help Google crawl and prioritize. Internal links should point to the final target URL rather than an intermediate redirected address, because redirect chains both waste crawl budget and dilute link-value transfer. Building a silo and hub structure strengthens topical authority; indeed, internal-link strategy is as much a part of technical SEO as keyword research and backlink work are. Regularly detect and fix broken internal links and redirect loops.

JavaScript SEO and Rendering

Google renders pages with a current version of Chrome and executes JavaScript, but rendering depends on resources and can be delayed. For content to be processed correctly, JavaScript and CSS resources must not be blocked by robots.txt. Removing noindex with JavaScript or providing a canonical different from the original HTML does not work. Use the History API instead of fragment (#) based routing, because Googlebot cannot reliably resolve hash fragment addresses. In single-page applications, return meaningful HTTP status codes, otherwise client-side rendering can lead to soft 404s. Google no longer recommends dynamic rendering as a long-term solution; the current advice is server-side rendering, static rendering or hydration. The details are in the JavaScript SEO basics.

The Relationship Between Structured Data and Technical SEO

Structured data, mostly using schema.org syntax, makes a page eligible for rich results. Let us clarify an important fact: structured data is not a direct ranking factor. Google's John Mueller stated in April 2025 that structured data does not make your site rank better and is used to display search features. All required properties must be provided for a specific rich result type, but eligibility does not guarantee display. Structured data must be placed on the page it describes and must not be blocked by robots.txt or noindex. A current example: FAQ rich results were removed from Google Search on May 7, 2026, but FAQPage remains a valid schema.org type and can be kept for its semantic value. We covered structured data and its validation tools in detail in our schema markup guide.

Technical SEO Audit: Tools and Checklist

The free core toolkit is Google Search Console, PageSpeed Insights, Lighthouse, the Rich Results Test and the Schema.org Validator. Search Console shows how Google experiences your site, while tools like Screaming Frog crawl the site structure from the bot's perspective; the two complement each other. You can audit indexing issues with the Search Console Pages report and the URL Inspection tool, seeing one by one why a page is not indexed. The practical audit flow is this: list 404 and 5xx errors, fix broken internal links with a single-step 301, reduce redirect chains to one hop, and confirm robots.txt does not block CSS and JavaScript. For sites with Turkish and English versions, set up hreflang with tr-TR and en-US, a reciprocal return tag and an x-default, and repeat the audit at least every six months. When the technical foundation is solid, E-E-A-T signals, strong content and visibility for AI search work far more efficiently; for a broader framework you can explore our SEO services.