What is Technical SEO and how does it control crawling, rendering, and indexation?
Technical SEO controls crawling by telling bots which URLs to fetch, rendering by making the content available in HTML, and indexation by signalling which URL should be stored. A blocked page, a soft error, or a duplicate without a preferred URL wastes that system. Fix the path from fetch to index before you tune phrases on the page.
- Crawl — the bot can request the URL and gets the page, not an endless redirect.
- Render — the words are in the HTML, not locked in a file the bot never runs.
- Index — one preferred URL is eligible to be stored, and copies point at it.
How do you configure robots.txt, XML sitemaps, and clean crawl budgets?
Use robots.txt to keep bots out of utility paths, not to hide a page you simply do not want indexed. Publish one XML sitemap of the canonical URLs you do want stored, and keep it free of redirects and error URLs. Crawl budget matters on large sites: spend fetches on the URLs that can rank.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xmlThat file is an example, not a file to paste unchanged. Read what robots.txt is before you block a path, and what an XML sitemap is before you submit one. Leave parameter copies and redirected URLs out of the sitemap.
How do you fix duplicate content, canonical tags, noindex rules, and 301 redirect chains?
Duplicate content is two URLs with the same main text. Pick one canonical URL and point the copies at it with a canonical tag, or redirect them if the copy should not exist. Use noindex only for a page that must stay reachable but should not be stored. Collapse a redirect chain so the first hop is the final URL.
- Choose the URL that should rank.
- Add a canonical tag on the copies, or redirect them if they should not exist.
- Use noindex only when the page must stay open and must stay out of the index.
- Shorten any redirect chain so the first request lands on the final URL.
The tag itself is explained in what a canonical URL is. Do not canonicalise every URL on the site to the homepage.
How do TTFB, Core Web Vitals (LCP, INP, CLS), and server response times impact rankings?
TTFB is the time until the first byte. A slow TTFB delays Largest Contentful Paint. Interaction to Next Paint suffers when the server or the scripts keep the main thread busy. Cumulative Layout Shift is mostly a layout problem, but a late-loading asset from a slow host can still shove the page. These measures affect whether a page feels usable.
| Measure | What it watches | Published good range |
|---|---|---|
| TTFB | Wait for the first byte of HTML | A contributor to LCP, not a Core Web Vital by itself |
| LCP | Largest contentful paint | 2.5 seconds or less is the published good range |
| INP | Interaction to next paint | 200 milliseconds or less is the published good range |
| CLS | Cumulative layout shift | 0.1 or less is the published good range |
These ranges are Google's published usability thresholds, not a promise of a ranking position. Measure a real URL rather than guessing from the host's brochure.
How does your web hosting infrastructure directly help or hurt Technical SEO?
Hosting helps technical SEO when the origin answers quickly, compresses responses, and stays close to the visitors who matter. It hurts technical SEO when the first byte is slow, the host is far from those visitors, or errors and timeouts waste crawl fetches. HTML that is built for each visitor still waits on the origin server.
A content delivery network can cache static files. It does not remove the wait for HTML that is built per visitor. Check a real URL with the website speed test. If the page itself is heavy, the fix is the website speed optimization service, not a claim that a plan name improves rankings.