Technical SEO

What is technical SEO?

Technical SEO is about creating the right technical conditions for Google to find, crawl, render, index and understand the right parts of a website. It is a core part of SEO for businesses, because even strong content can struggle to perform if search engines cannot reach the page, misread a URL or fail to see how the different parts of the site fit together. Technical SEO should always be paired with sound keyword research – otherwise you risk optimising the wrong pages technically.

The work covers crawlability, indexing, canonical tags, redirects, internal linking, site structure, JavaScript and performance. But technical SEO is not about eliminating every warning an SEO tool finds. A site can have plenty of minor technical remarks and still perform well, while a single mistaken noindex, a blocked key page or a faulty canonical can badly limit visibility.

That is why the most important part of technical SEO is to identify which technical problems genuinely affect the site’s organic potential and tackle them in the right order.

1. Can Google find the page?

Before Google can index a page, it first has to discover that the URL exists. That happens through internal links, external links and XML sitemaps, among other things.

An important page that sits in isolation from the rest of the site can therefore be harder to discover and understand, even if the page itself is technically sound.

2. Can Google crawl the page?

Once Google has discovered a URL, Googlebot needs to be able to reach it and fetch the content.

Robots.txt, server errors, faulty redirects and other technical restrictions can all affect crawling. It is also important to separate crawling from indexing: blocking Google from crawling a URL is not the same as telling it that the page should stay out of search results.

3. Can and should the page be indexed?

Just because Google can crawl a page does not mean it should be indexed.

Most websites have URLs with no reason to appear in search results. Technical SEO is therefore about ensuring that the right pages can be indexed and that Google gets clear signals about which version of the content to prioritise.

noindex, canonical tags, duplicate URLs and the structure of the site all play an important part here.

4. Can Google render and understand the content?

Finally, Google needs to be able to interpret the content and links that users actually see.

This matters most on sites where large parts of the content or navigation are built with JavaScript. If important information only becomes available after complex rendering, that can create further technical issues that need to be analysed.

Once these basics work, the site has a technical foundation to build on. From there, the work can move on to performance, Core Web Vitals, structured data and more advanced technical improvements.

The most important parts of technical SEO

Technical SEO is made up of several parts that together affect how efficiently search engines can discover, process and understand a site’s URLs. Not every part matters equally for every site. A small business site may have fairly simple technical needs, while an online shop with thousands of products, filters and URL variations can demand far more advanced handling.

The point, then, is not to optimise every technical detail, but to understand which parts genuinely affect the site’s ability to be indexed and to compete in search results.

Crawlability and internal linking

Google discovers a large share of the web through links. Clear internal linking therefore helps both users and search engines find important pages and understand how the different parts of the site relate.

Problems arise, for example, when key landing pages sit several levels deep, have no internal links or can only be reached through features that Google struggles to follow.

A technical analysis should therefore check not only whether a URL exists, but also how easily it can be discovered from the rest of the site.

Robots.txt and noindex

robots.txt is used to control which parts of the site search engine crawlers may request. noindex, on the other hand, tells search engines that a page should not appear in search results.

The difference matters. If Google is blocked from crawling a page, it may also be unable to read a noindex directive on the page itself.

Getting this wrong can have serious consequences. A common example is rules from a staging or development environment that carry over by mistake when the site launches.

XML sitemap

An XML sitemap is a list of the URLs the site owner wants to help search engines discover.

It is especially useful on larger sites, new sites, or sites where not every important page is easy to find through internal linking.

A sitemap is, however, no guarantee of indexing. If a URL is in the sitemap but also has noindex, the wrong canonical or very weak content, the sitemap file does not solve the underlying problem.

Canonical and duplicate URLs

The same or very similar content can sometimes be reachable through several URLs. This is common in online shops with filters, parameters, sorting and product variants.

A canonical tag can be used to state which URL should be treated as the main version.

A canonical is, however, a signal rather than an absolute command. Google may choose a different canonical if the other signals on the site point elsewhere. Canonicals, internal linking, sitemaps and redirects therefore need to give consistent signals about which URL is the primary one.

HTTP status codes and redirects

Status codes tell you what happens when a URL is requested.

A working page normally returns 200, while a removed page might return 404 or 410. When a URL is permanently moved to another address, a 301 redirect is normally used.

Problems arise when sites build long redirect chains, send users to irrelevant destinations or return 200 for pages that no longer exist.

On larger sites, faulty status codes can create thousands of URLs that search engines have to process needlessly.

Site structure and URL structure

A clear site structure makes it easier to see which areas matter most and how different pages relate to one another.

A services site might, for example, have a structure where the main services are supported by more specific subpages and guides. In an online shop, categories, subcategories and products may need to be organised in a way that is both logical for users and efficient to crawl.

URLs do not need to be extremely short, but they should be stable, readable and consistent.

JavaScript and rendering

Modern websites often use JavaScript for menus, filters, content and interactive features. Google can render JavaScript, so JavaScript is not an SEO problem in itself.

The problem arises when important links, content or metadata are not available in a way Google can discover and render correctly.

This is especially relevant for JavaScript-heavy frameworks, headless setups and sites where large parts of the content are only created after the page has loaded.

Technical SEO should therefore check what Google actually gets access to – not just what the user sees in the browser.

Core Web Vitals and performance

Performance mainly affects the user experience, but it is also part of Google’s broader page experience system.

Core Web Vitals measure, among other things, how quickly the main content appears, how responsive the page is and how much the content shifts while loading.

Poor scores deserve to be taken seriously, but they should not be prioritised above critical problems such as blocked indexing, faulty canonicals or pages Google cannot find.

100/100 in PageSpeed Insights is not an SEO goal in itself.

Structured data

Structured data is code that helps search engines understand what kind of information is on a page.

It can be used for products, organisations, articles, recipes, events and other content types that Google supports.

Correct structured data can make a page eligible for certain enhanced presentations in search results, but it does not replace good content and does not automatically mean better rankings.

The markup should therefore reflect the content that is actually visible on the page.

Hreflang for international websites

Sites aimed at several languages or geographic markets can use hreflang to help Google understand which version is intended for which audience.

It may be relevant, for example, if the same company has separate versions for Sweden, Norway and Denmark, or for different English-speaking markets.

A faulty implementation can, however, create confusing signals between the versions. For a site aimed only at Sweden, hreflang is normally not something that needs priority.

This also illustrates an important principle in technical SEO: not every technical option needs to be used on every site. The right technical solution depends on how the site is actually built and which problem needs solving.

Prioritise technical SEO problems in the right order

SEO can be priced in several different ways, depending on whether the work is ongoing, limited in scope or advisory. What matters most is not which pricing model is used, but that it is clear what is included and which problem the work is meant to solve.

5. Prioritise by impact – not by number of errors

A good technical SEO audit should therefore not end with an export of hundreds of issues from a crawler tool.

Instead, each problem needs to be assessed on:

• how many URLs are affected
• how important those URLs are to the business
• whether the problem affects crawling or indexing
• whether the user experience is affected
• how much SEO impact a fix could have
• how much work is needed to solve the problem

This means a technical problem affecting five important commercial pages can be prioritised above another problem that occurs on a thousand URLs but has no real business impact.

How to run a technical SEO audit

A technical SEO audit is not just about finding errors. The aim is to understand how the site’s technical structure affects crawling, indexing and the ability to grow organic visibility.

A good audit should therefore follow a clear process: first uncover the problems, then judge how serious they are, prioritise the right fixes and finally verify that the changes actually work.

1. Crawl the website

The first step is to build a technical picture of the site with a crawl.

A crawler tool can help identify, among other things:

• broken links
• redirects
• status codes
• canonical tags
• indexing directives
• duplicate URLs
• pages buried deep in the structure
• internal links
• technical metadata problems

The point is not to export the longest possible list of errors, but to use the crawl to understand how the site is actually built and which problems affect important pages.

2. Check indexing in Google Search Console

The next step is to compare the site’s technical structure with how Google actually handles its URLs.

In Google Search Console you can see, among other things, which pages Google knows about, which have been indexed and which have been excluded, and why.

Here you can spot problems such as:

• important pages that are not indexed
• the wrong URL version chosen as canonical
• pages that are discovered but not indexed
• noindex directives
• crawl problems
• redirects or soft 404 problems

This is an important difference from an ordinary crawl: the crawler shows how the site looks technically, whereas Search Console shows how Google actually interprets and handles parts of it.

3. Compare indexable and indexed URLs

Not every page that is technically indexable needs to be in Google.

So the question should not be only:

How many pages are indexed?

The more important question is:

Are the right pages indexed – and are the wrong pages filtered out?

A site might, for example, have thousands of indexed filter, tag or parameter URLs while important landing pages are missing.

A technical audit should therefore compare:

• which URLs should be indexable
• which URLs are actually indexed
• which URLs should not be indexed
• whether Google’s chosen canonical matches the site’s intent

4. Check canonicals, status codes and redirects

Next, review whether the site sends consistent signals about which URLs are the primary ones.

That means checking, among other things:

• canonical tags
• 301 and 302 redirects
• redirect chains
• 404 and 410 pages
• soft 404 problems
• whether internal links go straight to the right URL
• whether the sitemap contains URLs that redirect or should not be indexed

A common problem is that different technical signals say different things. A page might, for example, have a canonical pointing to one URL while internal links and the sitemap point to another.

The more consistent the signals, the easier it is for Google to see which version matters most.

5. Review site structure and internal linking

The next step is to assess where the most important pages sit in the site’s structure.

Questions worth asking include:

• can important pages be reached through ordinary internal links?
• do key landing pages sit unnecessarily deep?
• are there orphan pages?
• does supporting content back up the most important commercial pages?
• is the anchor text clear and relevant?
• are there parts of the site that are isolated from the rest?

Internal linking is therefore both a content issue and a technical one. A page that is built correctly but almost impossible to find in the site’s structure has weaker prospects than a page that is clearly integrated into the rest of the site.

6. Test performance and rendering

Once the basic crawling and indexing questions have been worked through, check how the site performs for both users and search engines.

That might mean reviewing:

• Core Web Vitals
• large images
• heavy JavaScript files
• render-blocking resources
• slow server response
• layout shifts
• content that only appears after JavaScript rendering
• links or navigation that Google may struggle to discover

It is important not to get stuck on individual scores from, say, PageSpeed Insights.

Performance problems should be prioritised by how much they actually affect the user experience and the site’s most important pages.

7. Prioritise fixes by real impact

When the analysis is done, the result should not be an unsorted list of hundreds of problems.

Each fix should be prioritised on:

• SEO impact
• business value
• how many important URLs are affected
• level of risk
• cost of implementation
• how quickly the fix can be verified

A simple prioritisation model could be:

Critical → High → Medium → Low

This lets you start with the problems likely to have the greatest effect, rather than spending time on technical details that barely change the outcome.

8. Verify after implementation

A technical SEO audit is not finished when the recommendations have been passed on to the developer.

After implementation, the site should be crawled again and the most important URLs checked afresh.

That might involve verifying, for example:

• that noindex has been removed, or added where it belongs
• that redirects work correctly
• that canonicals point to the right place
• that internal links have been updated
• that the page still renders correctly
• that Google can crawl the new version
• that the sitemap and other technical signals are consistent

Only once a fix is implemented and verified can the problem genuinely be considered solved.

Common technical SEO problems on different types of site

Technical SEO problems look different depending on how the site is built. A small WordPress site often carries very different risks from a large online shop or a JavaScript-heavy headless setup.

That means the same technical checklist should not be applied mechanically to every site. The analysis needs to start from the platform, the size of the site, the URL structure and how the content is actually generated.

WordPress

WordPress can be an excellent platform for SEO – but its flexibility also makes it easy to build in technical problems if the site is set up badly.

Themes, plugins, page builders, caching solutions and SEO plugins can all affect how the site is rendered, loaded, indexed and structured. If several systems are configured without a clear technical overall picture, the result can be anything from needlessly slow loading to faulty canonical tags, noindex, duplicate archives and JavaScript optimisations that interfere with important functions.

Common problems include:

• search engines being blocked through WordPress’s search engine visibility setting
• faulty noindex settings from SEO plugins
• duplicate or unnecessary category, tag and archive pages
• faulty canonical tags
• old redirects layered up over time
• slow loading because of heavy themes or too many plugins
• JavaScript and cache optimisations that affect functionality or rendering
• staging or test environments that accidentally become indexable

A poorly built WordPress site can therefore create significant technical debt that later limits SEO work. It can become especially problematic when new plugins and solutions are piled on top of a structure that was weak from the start.

But the opposite is also true.

When WordPress is built properly by someone who understands both web technology and SEO, it is a flexible and strong platform for organic growth. You can create clear site structures, control indexing, optimise performance and develop content without being locked into a rigid technical solution.

That is one of the reasons we work so much with WordPress at Skale. For us, it is not only about making a website look good – it has to be built with performance, structure, scalability and SEO in mind from the start.

Online shops

Online shops often have far more URLs, and far more automatically generated combinations, than ordinary business sites.

Technical problems can arise through, among other things:

• filters and faceted navigation
• sorting and parameter URLs
• product variants
• pagination
• products that have been removed
• products that appear in several categories
• thin or duplicate category pages
• faulty canonicals
• orphan products
• large numbers of indexable URLs with no clear search value

One of the most important questions is therefore which URLs should actually be indexable.

If every filter combination creates a new crawlable and indexable URL, a large share of search engines’ effort can go on pages that were never meant to compete in search results.

At the same time, not every filter should be blocked automatically. Some filtered combinations can have clear search demand and business value. Search intent and information architecture should therefore guide the technical solution here too.

JavaScript and headless

On JavaScript-heavy sites and headless setups, you need to check with particular care what search engines actually get access to.

Common problems can include:

• content that only loads after user interaction
• internal links that are not implemented as ordinary crawlable links
• metadata that is generated late or inconsistently
• new landing pages and supporting content
• faulty status codes
• canonical problems
• client-side redirects
• content that the user sees but that is missing from the rendered version Google receives
• large amounts of JavaScript that affect performance and rendering

Google can render JavaScript, but that does not mean every JavaScript implementation is automatically optimal for SEO.

For important commercial pages, core content, navigation and links should therefore be robust and accessible from a search engine’s perspective too, not just work visually for the user.

Vibe-coded and AI-generated websites

AI tools have made it possible to build websites far faster than before. With so-called vibe coding, large parts of a site can be created by giving instructions to an AI model rather than through traditional development.

For prototypes and simpler projects, that can be an efficient way to work. The problem arises when the generated code is published without anyone actually reviewing how the site is structured, rendered and performs from a technical SEO perspective.

When AI-generated code is reviewed, simplified and implemented by someone who understands web technology and SEO, the approach can be highly effective. When the code is instead published straight away simply because the page “looks right”, the risk of building in technical debt from the very first version goes up.

When technical SEO is not the problem

Technical SEO is the foundation that lets search engines find, crawl, index and understand a website. But once the technical foundation works, there comes a point where further technical tweaks deliver far less than other SEO efforts.

It is therefore important not to treat every ranking problem as a technical problem.

A site can be fast, correctly indexed and technically well built – and still have weak organic visibility.

Good technology cannot make up for the wrong content

If a landing page does not answer what the user is actually searching for, faster loading, cleaner code or more structured data will rarely solve the main problem.

The page may instead need:

• a better match with search intent
• clearer content
• a stronger offer
• better topic coverage
• a different type of landing page
• greater commercial relevance

Technical SEO creates the conditions for a page to compete. It does not automatically decide whether the page deserves to rank.

You may be targeting the wrong searches

Sometimes the site works technically exactly as it should, but the SEO strategy focuses on keywords that are too competitive, have no business value or carry a different search intent from the page trying to rank.

In that case, you do not need another technical audit.

What needs rethinking is which searches the company should prioritise and which pages should meet them.

Competitors may simply have stronger pages

If several technically sound sites compete for the same search, other factors become more important.

Competitors may, for example, have:

• better and more relevant content
• stronger commercial landing pages
• better topic coverage
• clearer internal linking
• greater established authority in the field
• more relevant external links

In that situation it is easy to keep looking for technical problems, because they are concrete and measurable. But shaving off a few more milliseconds of load time will not necessarily help if a competitor’s page is simply better for the search.

Not all technical improvements have the same business value

You can almost always find something technical to improve.

The question is whether that is the best use of the next hour or the next slice of the SEO budget.

If the site’s most important pages:

• can be crawled
• are correctly indexed
• use the right canonical
• work on mobile
• have reasonable performance
• are clearly integrated into the site structure
• can be rendered correctly

…the next investment may have a greater effect in other parts of the SEO work.

Technical SEO should solve problems – not create work

It is easy to turn technical SEO into a constant pursuit of perfection.

But the goal is not a website with no technical warnings. The goal is a website where the technology does not stand in the way of organic growth.

Once that foundation is in place, resources should move to whatever is currently holding progress back the most.

Sometimes that is technology. Sometimes it is content, search strategy, site structure, authority or the offer itself.

Good SEO is about being able to tell the difference.

Tools for technical SEO

Technical SEO tools help uncover problems, but they do not automatically decide what matters. A tool can show hundreds of warnings, while the real question remains which of them actually affect important pages and organic visibility.

It is therefore better to use a few tools with clear roles than to collect as much data as possible.

Google Search Console

Google Search Console is one of the most important tools for technical SEO because it shows how Google actually handles the site.

Here you can check, among other things:

• which pages are indexed
• why certain URLs are not indexed
• Google’s chosen canonical
• crawling and indexing problems
• Core Web Vitals
• sitemap status
• individual URLs through URL Inspection
• organic visibility, clicks and searches

Search Console is especially valuable because the data comes straight from Google and so complements what an ordinary crawler tool can see.

Screaming Frog

Screaming Frog is used to crawl the site in much the same way a search engine would follow links between URLs.

The tool can help find, among other things:

• status codes
• broken links
• redirects
• canonical tags
• noindex directives
• internal links
• crawl depth
• duplicate pages
• sitemap deviations

That makes Screaming Frog particularly useful when you want to understand how the site actually hangs together technically.

PageSpeed Insights

PageSpeed Insights is used to analyse the site’s performance and Core Web Vitals.

The tool combines lab data with real-user data where available, and can help identify problems with, for example:

• LCP
• INP
• CLS
• large images
• JavaScript
• render-blocking resources
• server response

The score in the tool should not, however, be treated as an SEO goal in itself. The focus should be on the problems that genuinely affect the user experience and key parts of the site.

Rich Results Test

Google’s Rich Results Test is used to check whether structured data on a page is correctly implemented and whether the page may be eligible for Google’s supported rich results.

It is especially useful after changes to, for example:

• Article
• Product
• Organization
• Breadcrumb
• LocalBusiness
• other schema types that Google supports

The tool shows both errors and warnings, but here too the results need to be judged against the type of content the page actually contains.

More tools may be needed on larger sites

On larger sites, tools such as Ahrefs, Semrush, Sitebulb or log analysis can provide further information on links, crawl patterns, competitors and site structure.

But more tools do not automatically mean better technical SEO.

What matters is combining the information from the tools and understanding:

What is the problem, which pages does it affect and is it worth prioritising?

It is the analysis and prioritisation that create the value – not the number of tools in the toolbox.

What does technical SEO cost?

The cost of technical SEO depends above all on how large and complex the site is, how serious the problems are and how much actually needs fixing.

A smaller WordPress site may sometimes need a fairly limited technical review, while a larger online shop, an international site or a JavaScript-heavy solution can call for considerably more analysis, development and follow-up.

A technical SEO audit can be run as a separate project

If the main need is to understand the site’s current technical state, a technical SEO audit can be carried out as a defined piece of work.

The work might cover, for example:

• crawl and technical analysis
• an indexing check
• canonicals and redirects
• site structure
• internal linking
• Core Web Vitals and performance
• rendering and JavaScript where relevant
• a prioritised action list

The price is then affected mainly by how many URLs need to be analysed and how complex the site’s technical structure is.

Implementation can be a bigger part of the cost than the analysis

Finding a technical problem is often easier than solving it.

On some sites a change can be made directly in WordPress or an SEO plugin. On others it requires development in the theme, backend, routing, templates or JavaScript.

It is therefore worth separating:

the cost of identifying the problems

from

the cost of implementing the solutions.

A comprehensive audit is not much use if the most important recommendations are never carried out.

Technical SEO can also be part of ongoing SEO work

For many businesses, technical SEO is not a separate project but part of ongoing SEO work.

Technical problems are then prioritised alongside landing pages, content, internal linking and other SEO efforts, according to where the greatest potential lies.

At Skale, local SEO starts from SEK 3,000 a month and ongoing SEO from SEK 5,000 a month, excl. VAT, but the right level depends on the site’s current state, the competition and the scope.

If you want to see what different budget levels can look like, read our guide to what SEO costs.

Pay for the right problems – not the biggest report

A larger technical report is not automatically more valuable than a smaller one.

If an audit finds 400 minor warnings but misses the three problems that actually limit the site’s most important pages, the work has been prioritised wrongly.

What matters is that the cost of technical SEO is in proportion to the problems to be solved and the business benefit the solutions can create.