Technical SEO audit

Strong content and a good structure are not enough if the site is technically broken. Google has to be able to crawl, index and understand your site. Otherwise, nothing else matters.

Technical SEO makes sure search engines can do their job. It is the foundation that everything else is built on.

However good the content is, there are almost always technical problems holding back visibility. Sites have generally improved, but new technical problems keep appearing as Google, modern browsers and web technology change.

We use several tools to compile a technical audit of every site we start working with. All the tools begin by crawling the site as Googlebot, so that we see the same things Google sees.

What we analyse

The checklist for the lowest acceptable technical standard keeps growing as Google changes. In recent years, HTTPS, site speed and Core Web Vitals have been added as critical points. Items are rarely removed from the list, and the requirements increase over time.

The technical audit always results in a prioritised list of actions. Some errors are catastrophic and must be fixed immediately. Others are micro-optimisations that bring marginal improvements.

The technical SEO audit often needs to be repeated after major releases. Old errors tend to come back, and new ones appear every time new functionality is built into a site.

The technical audit feeds into our website analysis. It helps us understand what opportunities or difficulties different page types have in reaching the top positions for important search terms.

Crawlability: can Google find your pages?

How robots.txt can block important pages

A misconfigured robots.txt can block Google from crawling important parts of the site.

We review robots.txt first in every technical audit.

What tends to go wrong in a sitemap?

XML sitemaps help Google find all the important pages on the site.

A good sitemap contains only the pages you want Google to index: no 404s, redirects or duplicates.

When does crawl budget matter?

Crawl budget matters above all for very large sites (from around one million pages) and for sites with more than 10,000 pages whose content changes daily. Google does not crawl every page every day.

Solution: Prioritise important pages, block unimportant ones and improve speed.

Indexing: does Google understand the pages correctly?

Canonical tags are the most common problem

Canonical tags tell Google which version of a page is the “real” one. Incorrect canonical tags are among the most common technical errors we see.

Problem: incorrect self-canonical

Incorrectly implemented canonicals are almost more common than missing ones.

These errors are common.

Why a correct self-canonical is critical

For a page that the site’s internal links reach at the URL https://www.exempel.se/katalog/sida, the canonical code should look like this:

<link rel="canonical" href="https://www.exempel.se/katalog/sida" />

A correct canonical is particularly important for sites that advertise a lot or have many partnerships. This is because Google all too often indexes variants of URLs containing different parameters.

Google can often handle UTM parameters, but if the URL contains an extra parameter, things can go wrong. With enough of these “alternative” URLs for a page, Google can easily get lost and start showing the parameter version of the URLs in the search results. The page then never reaches the position it deserves, because the site itself does not support the version of the page that Google has decided is the best.

A correct self-canonical also reduces problems between the www and non-www versions of a site. It also reduces the all too common problems with pages that respond identically with and without a trailing slash in the URL.

How the noindex and nofollow indexing directives are used

Sometimes you do not want certain pages to be indexed. That is when a noindex tag is used.

We review all indexing directives to check that the right pages are indexed and that the rest are blocked.

Structured data helps Google understand the content

Structured data (Schema markup) helps Google understand what the content is: a product, article, recipe, event and so on.

We always validate structured data with Google’s tools to check that the markup is correct.

How Core Web Vitals measure speed and user experience

Since June 2021, Core Web Vitals have been part of Google’s ranking systems. Google measures how real users experience the page.

What are the three Core Web Vitals metrics?

LCP (Largest Contentful Paint): loading time

How long does it take before the main content appears?

Target: Under 2.5 seconds

INP (Interaction to Next Paint): interactivity

How quickly does the page respond to user interaction?

Target: Under 200 milliseconds

CLS (Cumulative Layout Shift): visual stability

Does content jump around while the page loads?

Target: Under 0.1

We measure Core Web Vitals both in the lab (Lighthouse) and in the field (real users via Search Console).

How does the site cope with mobile-first indexing?

Google primarily indexes the mobile version of your site, so that is the version that counts.

What we review

Content parity

Does the mobile version have the same content as the desktop version?

If content exists in the desktop version but not on mobile, Google may miss it completely.

Mobile speed

Mobile devices are often slower than computers, so optimising for mobile is even more important.

We always test on real mobile phones, not just in simulations on a computer.

Are HTTPS and security on the site in order?

HTTPS is no longer optional but a requirement.

What we check

Mixed content

All resources (images, scripts, stylesheets) must be loaded over HTTPS.

Problem

An HTTPS page that loads HTTP resources triggers browser warnings and may be blocked entirely.

Solution

Update all internal links to HTTPS, load external resources over HTTPS or use a content security policy.

Redirects from HTTP to HTTPS

Make sure the HTTP version redirects to HTTPS with a 301.

When do rendering and resources become a problem?

Too many CSS and JavaScript files can make rendering harder

JavaScript-heavy sites and some centralised CMSs often generate many JavaScript and CSS files. This also worsens the user experience, because the sites become slower.

If a page loads too many different resources that affect its appearance, Googlebot may also struggle to render it correctly.

The limit is somewhat fluid. When it is reached, Google may suddenly stop loading the resources in its rendering. This shows up as odd-looking pages in Search Console and gives worse positions than the site should have, sometimes much worse.

Solution: Combine files, minify, and use code splitting and inline critical CSS.

JavaScript SEO: does Google render the content?

This applies to JavaScript-heavy sites (React, Vue, Angular).

The solution is often server-side rendering (SSR) or static site generation (SSG).

How to avoid errors with redirects and deleted pages

How 404s and redirects get handled wrongly

Do you often delete pages from your site? We strongly advise against it, at least without a well-considered 301 redirect to a page with reasonably equivalent content.

But it happens. Sites delete pages or change a page’s URL just because the heading changes, the colour of the product changes or the product is temporarily out of stock. In that case, we hope the page at least returns a proper 404.

Common errors

The deleted page redirects with a 302 (temporary) to a page that itself returns a 404. The target page may even return 200 OK, which means it exists and responds as it should, but has no text.

A working and not overly cumbersome function for creating 301 redirects is often fiddly to develop and implement, but it pays off in the long run.

How to do redirects correctly

Make sure redirects use the right protocol. There are many possible sources of error when the page https://www.exempel.se/katalog/foo is to be redirected to https://www.exempel.se/katalog/bar.

We have seen examples of redirect loops via http, via the non-www version of the site or a combination of both.

It is more common for the page to be redirected with a 302, which does not send the right signals to Google.

Another common error is that parameters are not carried over in the redirect, which breaks the tracking of advertisers’ campaigns.

How search results and filters create thin content

Search results pages instead of categories

For large sites, especially in media and retail, it is often important to optimise category pages rather than individual article or product pages. Articles and products have a short lifespan.

A shortcut to categorisation can be to work with search results pages, especially with modern technologies such as Elasticsearch, which can quickly and elegantly create content-rich pages.

But shortcuts are often thorny, and search results bring many problems.

The problem

Even if the defined results pages are good, you quickly create a flood of unexpected results pages based on what customers search for. Customers rarely search the way you imagined. There are spelling mistakes and searches for odd things that should not even be on the site.

You then create “thin content” on the site, meaning pages that have no content of their own but only list links to other pages.

Solution

We would rather see search results pages kept out of the index with noindex. If the goal is instead to save crawling, Googlebot can be stopped in robots.txt, but then Google cannot read the noindex on the pages.

For important categories: create real category pages with their own content, descriptions and SEO optimisation.

Filter pages in e-commerce create many URLs

Similar problems arise with filtering.

Every combination creates a new URL. With 10 colours, 5 sizes and 20 brands, that makes 1,000 URLs just for the combinations where all three filters are selected.

Are the URL structure and parameters set up correctly?

How URL parameters create duplicate content

URL parameters can create massive duplicate content problems.

Same content, different URLs.

Internationalisation: hreflang shows Google the right language and country

For sites in several languages or countries, hreflang is critical.

What hreflang does

It tells Google which language/country each version of the page is intended for.

We implement hreflang correctly and test that it works.

How we prioritise the actions after the audit

The action list is divided into levels:

Level 1: critical errors (must be fixed immediately)

• Robots.txt blocks important pages
• Noindex on main pages
• Incorrect canonicals pointing to 404s
• HTTPS missing or mixed content problems
• Many 404s or redirect chains

Level 2: serious problems (should be fixed soon)

• Core Web Vitals in the red
• Mobile usability problems
• Missing structured data
• Duplicate content problems
• Slow server response time

Level 3: optimisations (improve over time)

• Improve Core Web Vitals from amber to green
• Add more structured data
• Optimise crawl budget
• Improve internal linking technically
• Implement schema for more page types

As part of our ongoing SEO work, we often help with the implementation itself, from simple fixes to major technical changes.

Technical SEO requires ongoing monitoring and updating as Google evolves and the site changes.

Would you like a technical analysis of your site?

We review your site’s technical foundation and identify all the problems holding back your organic visibility.

Contact us for a technical SEO audit →