Technical SEO: the components, the checklist, and what to fix first

Technical SEO is the work of keeping a website's structure and infrastructure in a state where search engines can crawl it, read it, render it, index it and pick the right page to show, while the people who click through can actually use that page on their own device. It is not about what you write. It is about the condition your writing arrives in when Googlebot and a real user get to it.

The most valuable part of this guide is the section on ordering the fixes, because audit tools produce lists hundreds of lines long and none of them tell you where to start.

What technical SEO is

Technical SEO works on the layer underneath your content, so that the path from a URL being discovered to a page being served in search results has no break in it. That path has five stages, and each one fails differently.

• Discovery. The engine has to learn the URL exists, through internal links, external links, or an XML sitemap. Pages with nothing pointing at them usually stay undiscovered.
• Crawling. The bot requests the URL. A server error, a robots.txt disallow, or a timeout ends the process there.
• Rendering. Pages built with client-side JavaScript need scripts to run before the bot sees real content. If the main content depends on a blocked API call, the bot sees an empty page.
• Indexing. The engine decides whether to store the page, and when several URLs carry the same content, picks one to represent the group.
• Serving. Only indexed pages get ranked, and valid structured data makes a page eligible for enhanced result formats.

On-page SEO deals with what is on the page, off-page SEO with external signals such as links, and technical SEO with the conditions that let the other two count for anything. The SEO services page lays out how the three fit together. What it cannot do deserves the same clarity: it will not create demand for content nobody searches for. It only makes sure that everything you already spent effort on has a chance of being counted.

Why technical SEO matters

Technical SEO matters because it is a precondition. A page a search engine cannot reach or will not index ranks nowhere, regardless of how good the content is. A full year of content budget spent on pages carrying a leftover noindex tag produces exactly zero. The effect runs along two tracks at once.

• The ranking track. Visibility comes first: a page has to be indexed before it can compete. Then signal consolidation: if one piece of content is reachable at ten URLs, links spread across all ten instead of accumulating on one. Then continuity: sites that migrate platforms without a redirect plan routinely lose years of accumulated ranking in a week.
• The UX track. Almost every item on the same fix list affects real people. Pages that load slowly, buttons that jump away as a thumb comes down on them, links that lead to 404s, an expired HTTPS certificate that makes the browser throw up a warning. All of these make people leave before they see the offer.

The two tracks meet because Google measures part of page experience from real users, not from a lab test alone. Businesses maintaining Thai and English versions on one domain get a second layer of this through hreflang, which is why SEO in Thailand so often starts by clearing structural problems.

What you need to know in technical SEO

There are seven core component groups. You do not need developer-level expertise, but you do need to recognise each one when it breaks, so you can describe the problem to whoever will fix it.

1. Crawling and indexing

This is the most important group and the most misunderstood. The robots.txt file sits at the root of a domain and tells bots not to crawl URLs matching certain patterns. A meta robots tag with a noindex value sits in the head of a page and says something different: crawl this, but do not keep it in the index. The consequence worth memorising: if you disallow a URL in robots.txt and then place a noindex tag on that page, the noindex is never read, because a bot has to crawl the page to see a tag inside the page. That URL can still appear in search results if other sites link to it, just without a description. If the goal is removal from the index, leave the URL crawlable and apply noindex through the in-page tag or the X-Robots-Tag HTTP header. Two related checks belong here: 5xx errors in bursts slow crawling down, and crawl budget is a large-site concern rather than something a few hundred pages will hit.

2. Site speed and Core Web Vitals

Core Web Vitals consists of three metrics: LCP, when the largest piece of content in the initial viewport finishes rendering; INP, how quickly the page responds to user interactions; and CLS, how much the layout jumps during load. INP formally replaced FID in March 2024. Keep field data and lab data apart: field data comes from real users and is what Google uses to assess page experience, while lab data comes from a single simulated load and exists to diagnose causes. Slow LCP usually traces back to an uncompressed hero image or render-blocking CSS, poor INP to JavaScript holding the main thread, and high CLS to images and ads with no reserved space.

3. Mobile

Google indexes mobile-first, which means the mobile version of a page is the version used for indexing and ranking. One conclusion follows and it carries weight: anything not present in the mobile version effectively does not exist as far as Google is concerned. Sites that drop the specification table on mobile or load reviews only on desktop are discarding the material they compete with. Beyond content parity, check the meta viewport, tap targets and interstitials.

4. HTTPS and security

HTTPS carries traffic over TLS encryption, so an intermediary cannot read or alter it in transit, and Google has said it is a lightweight ranking signal. HSTS, delivered through the Strict-Transport-Security header, tells a browser to contact the domain over HTTPS only for a stated period, after which it refuses HTTP even if the user types it. Check that every version of the domain redirects to one canonical version, that no mixed content remains, and that certificates renew automatically, since an expired certificate can remove all traffic within minutes.

5. Structured data

Structured data labels the meaning of content in a machine-readable format, JSON-LD being the one Google recommends, and it makes a page eligible for enhanced presentation such as question and answer blocks or product information. The word to hold on to is eligible: it does not guarantee an enhanced result, it is not a ranking factor in itself, and Google decides whether to show it. What you control is that the markup matches what a user actually sees on the page.

6. XML sitemaps

An XML sitemap lists the URLs you want search engines to know about. Its job is discovery, not guarantee: inclusion does not mean a URL will be indexed, and absence does not mean it will not be. A single file can hold up to 50,000 URLs and must not exceed 50MB uncompressed; beyond that, split it and use a sitemap index file. Quality comes down to one rule: include only canonical, indexable URLs that return 200.

7. Duplicate content and canonical selection

Duplicate content within a single site is not a penalty. The search engine groups URLs with the same content and picks one to represent the group, and the URL it picks may not be the one you want ranking. The canonical tag states your preference, but Google treats it as a hint rather than a directive, so when other signals contradict it, the system may choose otherwise. Common sources of duplicates are tracking parameters, a site reachable with and without www or a trailing slash, and paginated listings. Google stated back in 2019 that it no longer uses rel="next" and rel="prev" for indexing, so handle paginated sets with crawlable links and self-referencing canonicals. Multilingual sites add hreflang, whose most common failure is a missing return link: if page A declares B as its alternate, B has to declare A back, or the annotation is ignored. Include an x-default for users matching none of the declared options.

A technical SEO checklist you can work through

The checklist below is grouped by area, not ordered by what to fix first. Collect findings with it, then run them through the prioritisation framework in the next section.

Visibility

• Open the domain's robots.txt and read it line by line. Does any Disallow rule cover a page you want to rank?
• Confirm no meta robots noindex or noindex X-Robots-Tag header is left in place. This is the single most common thing to escape from a staging server at launch.
• Work through the Page Indexing report in Search Console reason by reason, then spot-check important URLs with the URL Inspection tool.

URL correctness

• Every page declares a canonical, and the declared value points to a URL returning 200 rather than one that redirects.
• Pick one primary domain version, 301 the rest to it, and collapse redirect chains longer than two hops.
• Permanently removed pages return 404 or 410, and no page returns 200 while displaying a not-found message.

Performance and mobile

• Look at real-user LCP, INP and CLS grouped by page type rather than at a site-wide average.
• Identify which element is the LCP element on your important pages before trying to speed anything up.
• Images have dimensions set in advance, below-the-fold assets are lazy loaded, and unused third-party scripts are gone.

Security and data

• The whole site is served over HTTPS with no mixed content left, and certificates renew automatically with an alert before expiry.
• The XML sitemap contains only canonical, indexable URLs, is referenced in robots.txt, and has been submitted in Search Console.
• A before snapshot exists covering indexed page count, impressions and clicks.

Technical SEO problems: what to fix first

There is one governing rule. Anything blocking indexing gets fixed first, and everything else is ordered by impact. The reason this rule has no exceptions is that blocking problems multiply a page's value by zero, while every other kind of problem reduces it by some percentage. Multiplying by zero and multiplying by 0.8 are not two levels of urgency. They are two different categories of problem.

Step one: split the list into two piles

Walk the findings list once and ask the same question of every item: if this is not fixed, can the affected pages be indexed and selected for display at all? No means the first pile. Yes but worse means the second.

The first pile is usually short, and its items are usually the easiest fixes on the list: delete one line from robots.txt, strip a noindex tag left over from development. That ease is why they get skipped, since audit reports sort by affected URL count rather than by what severs visibility entirely.

Step two: order the second pile with three variables

The second pile needs judgement. Score each item on three variables and sort by the result.

• Value of the affected pages. Pages that generate revenue or leads outweigh archive pages with no traffic. Use actual data to decide which pages earn, not a sense of which feel important.
• Number of affected URLs. A problem living in a template affects every page built from that template, so one fix pays out thousands of times. A problem on one page pays out once.
• Effort and who has to do it. Something the marketing team can change in the CMS this afternoon and something that queues three weeks for a development sprint do not belong at the same position, even at equal impact.

Multiply value by page count and divide by effort. Real numbers are not needed; scoring each column high, medium or low produces an order. What this buys you most reliably is that template-level fixes rise to the top of the second pile, and those are almost always the highest return work in technical SEO.

Step three: do not ship everything at once

Shipping twenty fixes on the same day leaves a team unable, two months later, to say which of them worked. Ship the entire first pile immediately, since that is unblocking rather than experimenting, then ship the second pile in batches of one problem type each, recording the release date so it can be laid against indexing and impression charts.

Once shipped, use the validation control in the relevant Search Console report and the live URL test to confirm the bot now sees the fixed version. Do not assume a fix is live because the code deployed: CDN and CMS caches can serve the old version to bots for days.

The ordering table

This table compresses the framework into one screen. Use it to group audit findings before you ask the development team for time.

Technical SEO tools

Free tools are enough for most small and mid-sized sites. Paid tools buy speed across an entire site in one pass, and continuity of monitoring.

Free tools

• Google Search Console is the first-party record and the only place that tells you whether Google has actually indexed your pages. The Page Indexing report shows which URLs are indexed, which are not, and why; URL Inspection checks one URL and can run a live test of what the bot sees now. It also carries the sitemaps report, real-user Core Web Vitals data and crawl statistics.
• PageSpeed Insights puts real-user data and a lab test for one URL on a single screen, and Lighthouse with Chrome DevTools lets you re-test locally as often as you like. The network panel shows which files are heavy, the performance panel shows which script is holding the main thread, and comparing the rendered DOM against the page source is the most direct check for JavaScript rendering problems.
• Google's rich results test and the Schema Markup Validator confirm whether markup is valid and whether it qualifies for enhanced presentation.
• Bing Webmaster Tools gives a second search engine's view at no cost, and curl or any HTTP header viewer shows status codes, redirect destinations and headers such as X-Robots-Tag without a tool's interpretation in between.

Paid tools

• Screaming Frog SEO Spider is a crawler that runs on your own machine. The free version crawls up to 500 URLs per crawl; a paid licence removes that limit and adds JavaScript rendering and scheduled crawls.
• Sitebulb is a crawler that explains what each finding means and how much it should matter, which helps when the output goes to executives or developers.
• Ahrefs and Semrush include site audit modules that re-crawl on a schedule, so their strength is continuous monitoring and alerting when issue counts change.
• Server log analysis tools are the only way to see which URLs bots actually request, how often, and what status they receive, which becomes necessary once a site is large enough for crawl budget to matter.

Every tool shares one limitation: it reports what it found, not what to do first. No tool knows which pages earn money or how long the development queue is. Prioritisation stays a human judgement, and it is the core of what a serious SEO audit is for.

How often to run a technical SEO audit

There is no industry standard setting audit frequency by site size. Anyone quoting a fixed rule about how many months apart a site of a given page count should be audited is reporting a habit, not a search engine requirement. Set frequency from variables you can measure on your own site instead.

• Rate of change. A site adding pages daily or changing prices constantly produces new problems far more often than a ten-page company site edited once a year.
• Template blast radius. A site where every product page comes from one template carries the risk that a single template change breaks thousands of URLs at once.
• Release cadence. A team deploying weekly needs checking more often than a team that touches the site twice a year, because every deploy is an opportunity for a setting to change unintentionally.
• Total URL count. Size does not set frequency directly, it sets the cost of each pass. A site with a hundred thousand URLs cannot afford frequent full crawls, so it leans on automated monitoring.

Split it into three rhythms rather than one interval. The first is continuous monitoring: keep Search Console alerts on and review the Page Indexing and Core Web Vitals reports, watching for a sharp change rather than an absolute number, since a not-indexed count that jumps in a day means something shipped. The second is a periodic full crawl compared against the previous pass, which catches what makes no noise in reports: redirect chains that grew, canonicals that changed without anyone asking.

The third is event-triggered checking, which matters most and gets forgotten most: check immediately after a host move or domain change, a redesign or CMS change, a large plugin or theme update, and the moment search traffic drops abnormally. Frequency should track how often things break, not how many pages there are. A ten-page site whose team changes code weekly needs checking more often than a thousand-page site that has not moved in two years.

Summary and next steps

If one thing survives from this article, make it the order: confirm pages can be indexed, then that the right URL is indexed, then work on speed and experience, then on result enhancements. Doing it in the wrong order is why sites spend a month on structured data while half their pages are not in the index.

These fundamentals did not become less relevant as search shifted towards AI-generated answers. Anything that might cite your page still has to reach it, read it and understand its structure; the AI SEO page covers that side. If you want a prioritised list of findings with effort estimates attached, that is what an SEO audit from Relevant Audience produces.

Technical SEO FAQ

How is technical SEO different from on-page SEO?

Technical SEO covers the conditions that let a page be discovered, crawled, rendered and indexed, while on-page SEO covers what is on the page itself, such as headings and content structure. They overlap at title tags and canonicals. If the technical layer is broken, the best on-page work goes unseen.

Why does a page blocked in robots.txt still show up in search results?

Because robots.txt blocks crawling, not indexing. If other sites link to that URL, Google may index it without ever reading its content and display it without a description. To remove a page from the index, drop the Disallow rule so bots can read the page, then apply noindex through the meta robots tag or the X-Robots-Tag header.

Will adding schema markup improve my rankings?

Structured data is not a ranking factor in itself. It provides eligibility for enhanced presentation in search results, which can improve click-through rate at the same position, and eligibility means exactly that, since Google decides whether to show it. Adding schema to a page that is not indexed yet achieves nothing.

Should I use a canonical tag or a 301 redirect?

Use a 301 when the old page should stop existing and users go permanently to the new one, and a canonical when both URLs stay reachable but should count as one page. A 301 says the move is permanent, a 302 says it is temporary and the original stays the main URL, and a canonical is only a hint.

How long after a technical fix before results show?

There is no officially published timeframe, and it depends on when the search engine next crawls the fixed pages. What you control is signalling completely: update the sitemap, request inspection of key URLs in Search Console, and use the validation control in the relevant report. Measure with indexed page counts and impressions rather than the rank of one keyword.