What is technical SEO? Fourteen checks that matter

When a business starts doing SEO, the first things it usually thinks of are “keywords, articles, and rankings.”

But even if the content is well written, if search engines can’t properly discover, access, parse, and index the site’s content,

that content may still fail to show up properly in search results.

This is the problem technical SEO is there to solve.

Technical SEO isn’t about “how an article should be written.” It’s about whether the website itself has a sound technical foundation for search engines.

This article explains in full:

What technical SEO is, how search engines crawl and index a website, and how to understand and check key technical SEO items such as robots.txt, sitemaps, canonicals, redirects, JavaScript SEO, structured data, and Core Web Vitals.

You don’t need to become an engineer first.

But if a business wants SEO to become a long-term source of search traffic, it should at least understand whether its own website has the technical foundation search engines need to do their job.

Technical SEO is the optimization of a website’s technical architecture so that search engines can properly:

Discover

↓

Crawl

↓

Render

↓

Index

↓

Serve the content in search results

Put simply, technical SEO deals with:

That makes it different from the SEO content writing we discussed earlier.

SEO content is concerned with: “What content should we provide?”

Technical SEO is closer to: “Can search engines correctly process that content?”

Suppose a business has created a very thorough SEO article.

The content itself is fine, but the site might have issues like:

robots.txt blocking search engines from crawling

↓

Google can’t fetch the content properly, or the page is set to noindex

↓

Google can crawl it, but has been told not to add the page to the search index.

Or the same content exists at several different URLs

↓

The search engine has to decide which URL is the main version.

That’s when you may need a canonical URL

Or say a redesign changes /old-page to: /new-page

If the old URL simply disappears without an appropriate redirect, it can cause:

All of these are problems technical SEO deals with.

Technical SEO isn’t done just because you installed an SEO plugin or set up a sitemap.

It usually involves many layers of the website, such as:

And these items can affect one another.

For example, even if a URL is listed in the sitemap, if the page itself is set to noindex

the signals contradict each other.

Or the canonical points to: https://example.com/page

but that URL itself redirects to: https://example.com/zh/page

In that case the canonical isn’t pointing to the final, indexable canonical URL.

So what really matters in technical SEO isn’t “whether every feature has been done.”

It’s whether the site’s technical signals are consistent as a whole.

For a company website, one of the most efficient approaches to technical SEO isn’t to require every content editor to understand technical SEO. It’s to:

have the website platform itself set sensible default behavior.

For example, our platform currently does the following automatically:

Content managers don’t need to relearn how canonicals, sitemaps, and hreflang should be set up every time they create an article.

These rules are better handled centrally by the website system.

That doesn’t mean all technical SEO should be fully automated, though.

For example:

These may still call for SEO, content, and business judgment.

In the end, technical SEO still serves the site’s content and its users.

For example:

So technical SEO isn’t a set of “SEO tricks only Google can see.”

A more sensible way to understand it is:

When businesses invest in SEO, what they see most easily are keywords, articles, search rankings, and traffic.

But all of that work shares one prerequisite: “search engines must first be able to correctly fetch and process the site’s content.”

If a site has technical SEO problems, even great content may fail to deliver its search value because of incorrect technical settings.

Google has to discover a page before crawling, indexing, and appearing in search are even possible.

Search engines can discover URLs in different ways, such as:

So even after a page is published, if:

it can reduce how efficiently search engines discover and process the content.

One of the jobs of technical SEO is to build a clear site structure that search engines can discover.

Once it finds a URL, the search engine still has to actually access the page.

This involves:

For example: robots.txt

If important content is blocked by mistake, it can stop search engines from crawling properly.

That’s why robots.txt, though it looks like just a small file in the site’s root directory, is actually a very important foundational setting in technical SEO.

This is a concept businesses often mix up.

Google being able to crawl a page:

doesn’t mean the page will make it into Google’s index.

For example:

The page might be set to noindex

Or Google may finish crawling and still decide not to add the page to the index.

So “crawling ≠ indexing”

and “indexing ≠ a guaranteed ranking.”

Technical SEO can help search engines process a site correctly, but it can’t guarantee that “if every technical setting is correct, Google will definitely index or rank it.”

Company websites can easily end up, because of:

with multiple similar URLs.

When that happens, search engines may need to decide which one is the main version.

Technical SEO can use:

to build more consistent URL signals.

Our platform takes the same approach. For example, canonicals use the canonical public URL rather than an intermediate URL that will redirect again, and the sitemap likewise outputs the canonical public URLs.

It looks like a tiny technical detail, but the core idea is not letting your own site give search engines several different answers at once.

Technical SEO matters especially during a redesign.

Suppose a URL that has already earned rankings and external links, /seo-guide

becomes /resources/seo-guide after the redesign.

If the old URL isn’t handled, users and search engines may land straight on a 404 Not Found

The more sensible approach is usually to map old pages to new ones and, where appropriate, set up permanent redirects.

So a redesign can’t just check “does the new site open properly?”

You also need to work out how the URLs and search assets the old site has built up will be migrated.

That’s why SEO migration is an important part of any redesign in its own right.

When a small site has only a dozen or so pages, many SEO issues can be checked by hand.

But once the site starts to have:

relying on manual work for every technical SEO setting makes mistakes very likely.

So a mature platform should generally handle systematically anything that can be standardized.

For example, when a content slug is changed, our platform currently creates a permanent redirect from the old URL to the new one, and the sitemap is generated dynamically from actual publishing and indexing status instead of asking managers to maintain the XML by hand.

The biggest value of this approach isn’t “having more SEO features.”

It’s lowering the chance of technical SEO errors creeping in as the site is maintained over the long term.

Finally, avoid the opposite extreme: “our technical SEO is excellent, so content doesn’t matter.”

Suppose:

If the site’s content doesn’t genuinely answer search needs, that still doesn’t mean the site will earn good rankings.

Conversely: excellent content + serious technical SEO problems

can also hold back how that content performs in search.

So the more sensible relationship is:

The two don’t replace each other; they are different foundations of an SEO strategy.

SEO involves a lot of work, so you’ll often see the three categories “technical SEO, on-page SEO, and off-page SEO.”

They aren’t three independent SEO methods; they deal with problems at different levels.

The simplest way to understand them:

Technical SEO mainly deals with how search engines access and process the site.

Common items include:

For example:

The site has a great article, but it has been mistakenly set to noindex.

That isn’t a problem with how the article was written; it’s a technical SEO problem.

Or a redesign changes many URLs without setting up correct redirects.

That’s technical SEO too.

On-page SEO focuses mainly on the content and optimizable elements within the site’s pages.

For example:

Say a user searches for: “How do you write an SEO article?”

but most of the page is about: “Why do businesses need SEO?”

Even with technical SEO working perfectly, this page may still not satisfy the search intent well.

That’s a problem leaning more toward on-page SEO / content SEO to fix.

Off-page SEO happens outside your own website.

The most common item is backlinks.

For example, other relevant websites cite your research, articles, or tools in their own content and link back to your site.

Beyond that, off-page SEO can also involve:

But one point needs special attention here:

Off-page SEO ≠ buying lots of external links.

Buying, exchanging, or mass-building links to manipulate search rankings can fall under Google’s link spam policies.

That’s why it makes more sense for businesses to think of off-page SEO as building brand and content assets that other sites want to mention and cite,

rather than finding ways to get as many backlinks as possible.

Although SEO can be split into these three types, in practice they aren’t completely separate.

For example:

A business publishes a great research article.

On-page SEO → Search demand, content, title, and headings are all handled well.

But technical SEO → the page has mistakenly been set to noindex.

Then the content may not appear in search results at all.

Conversely:

Technical SEO is working perfectly, but the content quality is poor.

That doesn’t mean: “the site’s technology is great, so rankings will follow.”

Or take an article with genuine original research and industry value: other sites may cite it, which in turn generates:

natural backlinks for off-page SEO.

So the three are related:

This is a question that often comes up when categorizing.

The answer is: it relates to both.

So there’s no need to agonize over: “which single category does this item belong to?”

SEO categories mainly help us understand problems; they aren’t rigid technical boundaries.

It’s not a fixed sequence of: Technical → On-page → Off-page

where you finish one completely before starting the next.

The more sensible step is to first check: are there any major technical problems blocking SEO?

For example:

Problems like these should be fixed first.

Once the site has a basically healthy technical foundation, you can keep working on content, on-page SEO, and off-page SEO.

So technical SEO is more like the infrastructure of website SEO.

It isn’t something you do once and never touch again; it needs ongoing maintenance as the site adds features, grows its content, gets redesigned, changes domains, and adds languages.

To understand technical SEO, you first need to understand how Google processes a website.

Many people think of Google sees the site → the site appears in search results as a single step.

In reality, there are several stages in between.

A simplified view looks like this:

Discovery (finding the URL)

↓

Crawling

↓

Rendering

↓

Indexing

↓

Serving (showing search results)

Each stage deals with different problems and maps to different technical SEO issues.

Before crawling, Google first needs to know: this URL exists.

Google can discover URLs in different ways, such as:

For example, a business publishes a new article: /blog/technical-seo

If the homepage, article list, category pages, or other content link to it properly, Google can follow those links and discover the new URL.

An XML sitemap can also provide the important URLs the site wants search engines to know about.

So both internal links and sitemaps affect URL discovery.

But note: Google discovering a URL doesn’t mean it will crawl it, and crawling doesn’t mean indexing.

These concepts have to be kept separate.

Once Google discovers a URL, Googlebot may try to access it.

This process is called crawling.

When the web server receives the request, it returns:

and other resources.

This is where technical SEO starts to involve:

For example: /important-page actually exists, but robots.txt forbids Googlebot from crawling it.

Google may then be unable to fetch the page’s content properly.

So the crawling stage mainly answers:

Traditional HTML sites can usually deliver the main page content straight from the server.

But modern websites use a lot of JavaScript.

On some sites, the HTML returned on the first request contains very little content, and the actual:

only appear after the browser runs JavaScript.

This is where rendering comes in.

Google can run JavaScript and render pages, but that doesn’t mean businesses can ignore JavaScript SEO entirely.

What matters more is confirming: can Google properly fetch and render the main SEO content?

You don’t need to understand every front-end technology here, just one core difference.

None of these three approaches is “automatically better for SEO just because you use it.”

What you really need to confirm is: can Google reliably get the page’s main content and links?

The TimTech platform currently uses the Next.js App Router, and public pages are built with a mixed Server Component + Client Component architecture.

The main SEO content, such as:

is output mainly by Server Components.

Interactive features, such as:

are the only parts handed to Client Components.

So even if a user disables JavaScript, the main text content is still in the HTML; JavaScript mainly handles interaction rather than leaving the whole body of SEO content to be generated in the browser.

This is a very practical technical SEO principle: don’t make important content depend entirely on client-side JavaScript to appear unless there’s a real need.

After Google crawls and processes a page’s content, the next possible stage is:

Indexing.

Google analyzes the page, for example its:

and decides how to include the page in its search index.

It’s worth stressing again: successful crawling ≠ guaranteed indexing.

For example, if a page is set to: noindex

it explicitly tells search engines: don’t add this page to the search index.

Also, even if a site allows indexing, that doesn’t mean Google will add every page to its index.

So the question “We’ve already submitted the sitemap, so why hasn’t Google indexed it?”

itself wrongly treats sitemap → indexing as a guaranteed relationship.

A sitemap can help Google discover and understand URLs, but it can’t guarantee that pages will be indexed.

Only after a page is in Google’s index, and a user searches, does Google use:

to decide which results should be shown, and in what order.

So: indexing ≠ ranking.

This is also an important boundary for technical SEO.

Technical SEO can help a site build a sound foundation for crawling, rendering, and indexing.

But you can’t conclude from that: once technical SEO is all done, Google will definitely rank the site first.

Actual search rankings still involve many more factors, such as content, relevance, quality, and site and external signals.

Here’s a quick way to think about it:

So when a business finds: “Google can’t find this page.”

it shouldn’t immediately conclude: “Is the article’s SEO writing just bad?”

It should first find out at which stage the problem actually occurs.

Technical SEO covers a lot of ground, but you don’t need to think of it as a pile of unrelated technical settings.

An easier way to understand it is to go back to the search engine process described earlier:

Can the search engine find the page?

↓

Can it crawl it properly?

↓

Can it fetch and understand the content?

↓

Should it be indexed?

↓

Which URL is the canonical version?

↓

Does the site send clear, consistent technical signals?

Seen this way, the common technical SEO work on a company website can be organized into the following 14 key points.

The most basic first step in technical SEO is whether search engines can properly access important pages.

If Googlebot can’t fetch a page, everything that follows:

may fail to do its job.

So you need to check:

A technical SEO audit usually starts by checking whether the site can actually be crawled properly as well.

robots.txt is a file in the site’s root directory that tells search engine crawlers which paths on the site may or may not be crawled.

For example:

This asks general search engine crawlers not to crawl /admin/.

But there’s one very important concept:

If you really want a page kept out of the search index, you should usually use: noindex

rather than relying on robots.txt alone.

We’ll explain this difference separately later.

An XML sitemap can tell search engines which important URLs on the site you want discovered and crawled.

For example, a company website might include:

These official public pages can be listed in the sitemap.

But a sitemap isn’t: “submit it and Google will definitely index everything.”

It’s mainly a mechanism for URL discovery and for hinting at information about the site.

Our platform also generates the sitemap dynamically from content that is actually published and allowed to be indexed, rather than putting every system URL into it.

Some pages need to exist on a site, but that doesn’t mean they should all appear in Google search results.

For example:

In these cases you may need to use:

to tell search engines that support this directive not to add the page to the search index.

So:

Being crawlable and being allowed to be indexed are two different things.

When the same or very similar content can be reached through different URLs, canonicals come into play.

For example: /product?id=123 and /products/example may show highly similar content.

Using:

you can give search engines a signal about which URL is the preferred main version.

But a canonical isn’t a redirect, and it doesn’t force Google to “only ever use this URL.”

It’s one of the important signals for canonicalization.

An HTTP status code tells browsers and search engines: what happened with this URL request.

The ones technical SEO runs into most often are:

Correct status codes help search engines understand: what state the URL is actually in right now.

When a URL changes permanently, you usually need to consider setting up a permanent redirect.

For example:

/old-seo-guide

↓

/seo-guide

That way, users and search engines that visit the old URL are taken to the new canonical URL.

When the slug of an article, product, or category is changed, our platform automatically keeps the old URL and creates a permanent redirect, instead of letting the original URL turn into a 404.

But redirects shouldn’t be overused either.

For example: A → B → C → D

An overly long redirect chain like this suggests the site’s long-term URL management may need tidying up.

A site’s URLs should make it easy for users and search engines to understand how the content is structured.

For example: /resources/seo/technical-seo

is usually, compared with: /page?id=93847&type=12,

easier to understand.

But technical SEO doesn’t require cramming lots of keywords into URLs.

What really matters is:

Internal linking isn’t just content SEO.

It also affects how search engines discover the site’s pages and understand its information architecture.

For example:

Homepage

↓

SEO solution

↓

Complete SEO guide

↓

SEO keyword research

↓

SEO content writing

Ordinary HTML links like these let search engines follow the site’s structure to discover content.

So important pages shouldn’t become: orphan pages that no other page on the site links to.

Modern websites make heavy use of:

So you need to confirm whether search engines can properly get the main content and links on a JavaScript site.

What really deserves attention isn’t “using JavaScript is bad for SEO.”

It’s: whether important content relies too heavily on client-side rendering, and whether Google can reliably get the final content.

On our platform, public content is currently output as HTML mainly by Server Components, with interactive features handled by Client Components, which divides the work between functionality and indexable content.

Google uses mobile-first indexing, so the mobile version of a site’s content is very important.

Businesses should check that:

Technical SEO isn’t just “the mobile layout doesn’t look broken.”

You also need to confirm: whether the mobile version still provides all the important content.

A company website should use HTTPS to provide an encrypted connection.

Beyond security, you also need to avoid having both: http://example.com and https://example.com

as two browsable official versions of the site.

You should usually set up consistent HTTP → HTTPS redirects and canonical signals.

On our platform, custom domains also have TLS / SSL handled automatically by Vercel, with HTTP redirected to HTTPS.

Structured data uses a standardized format to help search engines understand the entities and information on a page more precisely.

Common examples include:

The common implementation format is JSON-LD.

But note: structured data ≠ guaranteed rich results ≠ adding schema directly raises your rankings.

More important is that the schema must match the content the page actually shows.

For example, when a product on our platform has no actual price and uses “request a quote” mode, we don’t make up an Offer price just to make the schema complete.

That matters more than “the more schema fields you fill in, the better.”

Finally, there’s the item businesses most often equate with technical SEO: site speed.

Google’s Core Web Vitals currently consist mainly of:

Site performance is certainly worth optimizing.

But don’t treat: a PageSpeed Insights score of 100

as the ultimate goal of technical SEO.

What really deserves attention is whether the site provides a good real-world experience and has no serious performance problems.

Seeing this list, it’s easy to turn technical SEO into yet another 14-item SEO checklist.

But what really matters is understanding how these settings relate to each other.

For example, the sitemap says this URL is important,

but noindex says not to index it.

Or the canonical points to URL A,

but URL A redirects to URL B.

Both mean the site itself is sending inconsistent technical signals.

So what technical SEO should really aim for is:

robots.txt is a text file in the site’s root directory that tells search engine crawlers which paths on the site may or may not be crawled.

For example:

This means: asking all search engine crawlers that follow the rules not to crawl the /admin/ path.

So what robots.txt mainly deals with is how search engines crawl the site,

not controlling whether a page will definitely appear in Google’s index.

These two concepts are very important.

A company website can use robots.txt to manage areas of the site it doesn’t want search engines crawling heavily.

For example:

You can also provide the sitemap location in robots.txt, for example:

Search engines can then get the sitemap location from here.

Our platform also generates robots.txt dynamically: by default it allows public content to be crawled while blocking system paths such as /admin/, /api/, /preview/, and /``_next/, and it provides the sitemap URL.

This is one of the most common SEO misconceptions about robots.txt.

Suppose a business has a page: /private-page

and then sets:

What this does is ask search engines not to crawl this URL.

But it can’t simply be read as “Google will definitely never show this URL in search results.”

If Google learns about the URL from somewhere else, such as an external link, the URL can still be discovered.

So if you really want a publicly accessible page kept out of Google’s index, you should usually use:

rather than robots.txt alone.

There’s another very important piece of technical SEO logic here.

Suppose the page itself is set to:

but robots.txt also sets:

This can cause problems.

The reason is that Google has to crawl a page before it can see the noindex directive on it.

If robots.txt already blocks Google from crawling, Google may not be able to read the noindex on the page.

So if the goal is “let Google access the page, but don’t add it to the index,”

the more sensible setup is allow crawling + noindex

rather than Disallow + noindex.

This is also why businesses need to understand crawling control and indexing control separately.

Another common mistake is treating robots.txt as a way to protect private content.

For example:

doesn’t mean users can’t simply type in example.com/confidential/ to reach the page.

robots.txt is itself a public file that anyone can view.

So if the content is genuinely:

it should be protected with authentication, authorization, or other real access controls,

not by relying on robots.txt.

Some sites, to “keep Google from crawling too much,”

block large amounts of CSS, JavaScript, or other site resources.

But search engines may need these resources to render the page correctly.

So you shouldn’t Disallow everything simply because “it isn’t article content.”

What you really need to check is whether Google needs these resources to correctly understand and render the page.

For a typical company website, robots.txt usually doesn’t need to be very complex.

A sensible set of principles is:

Don’t mix these four situations together.

The most serious case is accidentally blocking the entire live site.

For example:

means asking search engines not to crawl the entire site.

This setting sometimes appears in staging / test environments.

If it isn’t removed when the site goes live, it can cause serious SEO problems.

So whenever a site launches or is redesigned, robots.txt should be on the technical SEO checklist.

Our platform currently handles robots.txt with sensible system-generated defaults + additional rules each tenant can set

That’s the approach we take.

The system keeps the essential technical SEO rules, such as blocking the admin area and APIs; users can add their own Disallow / Allow rules, but they can’t override the system’s protective rules.

The point isn’t to restrict users, but to reduce the chance of a misconfigured robots.txt breaking the whole site’s technical SEO foundation

— that’s the risk we want to lower.

An XML sitemap is a list of the site’s URLs provided to search engines, helping them understand:

which important pages on the site you want discovered and crawled.

For example, a company website might have:

All of these official, public URLs with search value can be included in the XML sitemap.

A common URL is: https://example.com/sitemap.xml

As mentioned earlier, Google can use:

to discover new URLs.

So one of a sitemap’s main values is:

A sitemap is especially helpful when a site is large, updates content frequently, or has pages that aren’t easy to discover quickly through site navigation.

This is another very common misconception among businesses.

Putting a URL in the sitemap:

What a sitemap provides is “these are the important URLs the site wants search engines to know about.”

But Google still decides for itself whether to crawl and index these pages, and how to handle them.

So if Search Console shows: Sitemap Submitted Successfully

you can’t take that to mean: “SEO indexing is done.”

You still need to check the actual Page Indexing status.

A very practical principle is:

For example:

Suitable to include

Usually should not be included:

Because if the sitemap tells Google “this is an important official URL,”

but the page itself tells Google “don’t index this,”

the site is sending signals that contradict each other.

Suppose the site has https://example.com/product-a

but that page’s canonical is https://example.com/products/product-a

Then it makes more sense for the sitemap to list https://example.com/products/product-a

in other words, the canonical URL.

Likewise, if /old-page

already permanently redirects to /new-page

the sitemap should list /new-page directly

rather than keeping the old URL.

So a sitemap isn’t just “a list of every URL on the site.”

It should be a list of the official URLs the site wants search engines to process.

An XML sitemap can also provide <lastmod>

to indicate when the page last had a significant content update.

For example:

But lastmod shouldn’t turn into everything being updated to today every time the sitemap is regenerated.

Because then it loses its meaning as “when the content was actually updated.”

Our platform also generates lastmod from the content’s real updated``_at, instead of rewriting every page’s date to the current day each time the sitemap is requested.

It’s a small but important implementation detail: if you provide information, the information itself should be trustworthy.

Besides listing the URLs of each language version, a multilingual site can also use hreflang

to describe the relationships between different language or regional versions.

For example:

These aren’t three unrelated pages; they may be different language versions of the same content.

Our platform outputs language version information in the sitemap, including the corresponding hreflang relationships.

International SEO is covered in more depth later.

For a modern CMS or dynamic site, I don’t recommend maintaining the sitemap manually.

Suppose a business has: 500 articles + 300 products + 3 languages

If every time you:

you have to edit the sitemap by hand, mistakes are easy to make.

The more sensible approach is to have the website system generate the sitemap dynamically based on the actual state of the content.

Our platform currently uses:

to generate the sitemap automatically.

Technical SEO work that can be clearly turned into rules like this is well suited to being handled by the system.

Strictly speaking, not every site needs a sitemap to be discovered and indexed by Google.

If a site:

Google may still discover its content just fine.

So a sitemap isn’t a case of “no sitemap, no SEO.”

But for a typical company website, creating a sitemap costs very little and gives search engines clearer URL information.

It’s especially worth creating for:

where it pays off even more.

So our practical recommendation is still simple:

The point isn’t that “you can’t rank without one,” but that it’s a low-cost, easily standardized piece of technical SEO groundwork that helps search engines discover important URLs.

Once the sitemap is created, you can submit it at:

Google Search Console → Sitemaps

Then you can check whether Google is able to read the sitemap properly.

But remember: the sitemap being read successfully and the site’s pages being indexed successfully are two different things.

To really judge indexing status, you need to look at the Page Indexing report together with URL Inspection.

A canonical URL gives search engines a signal about:

which URL is the site’s preferred main version when multiple URLs have identical or highly similar content.

It’s usually set in the HTML like this:

This URL is usually called the canonical URL (the standard / main version URL).

Businesses don’t necessarily create duplicate content on purpose.

Often, the website system naturally generates different URLs.

For example:

If these URLs serve identical or very similar content, canonicalization may come into play.

Even if a page has no obvious duplicate versions, you can have the official page point to itself.

For example, if the current official URL is https://example.com/technical-seo

you set:

This is called a self-referencing canonical.

It lets the site state more clearly: “this is the official URL for this page.”

The TimTech platform takes this approach as well, generating canonicals automatically from each page’s official public URL.

These two concepts are easy to confuse.

Suppose there are URL A and URL B.

Users can still visit A.

But A tells search engines “B is my preferred main version.”

When users visit A, they’re taken straight to B.

So if the old URL has been permanently replaced by a new one,

you should usually consider a permanent redirect.

If multiple URLs still need to exist for site functionality, but their content is highly similar,

a canonical may be the right fit.

The two can’t be treated as exactly the same tool.

Another important point: Google may not necessarily use the canonical the site specifies.

Google weighs various signals to decide the main version, such as:

So in Google Search Console you may see a user-declared canonical and a Google-selected canonical,

and the two aren’t necessarily the same.

If Google consistently picks a different canonical, you should check whether the site is sending contradictory signals.

Suppose the site specifies /new-page as the canonical.

But the sitemap still lists /old-page

and lots of internal links point to /old-page

while the canonical points to /new-page

At that point, the site itself is giving different answers.

Ideally:

Canonical

→ /new-page

Sitemap

→ /new-page

Internal Linking

→ /new-page

And if the old URL has been permanently replaced:

Redirect

→ /new-page

Keep the main signals as consistent as possible.

That matters more than simply “is there a canonical tag?”

This is a detail from our platform implementation that’s well worth sharing.

Suppose the real official URL is https://example.com/zh-TW/about

but the canonical is written as https://example.com/about

and /about in turn redirects to /zh-TW/about

That creates canonical → redirect → final URL.

The cleaner approach is for the canonical to point directly to the final official URL.

So when our platform generates canonicals, it uses the tenant’s official public URL and locale path directly, rather than an intermediate URL that will redirect later.

The same principle applies to:

Have SEO signals point directly to the final official URL wherever possible.

This is another area that’s often set up wrong.

For example:

If these three pages really are different language versions of the content, you usually shouldn’t canonicalize the English and Japanese versions to the Chinese one.

Otherwise you may effectively be telling search engines: the Chinese version is the main one.

The more sensible approach is usually a self-canonical for each language version,

with hreflang describing the relationships between the language versions.

Our platform likewise has the canonical point to the current language’s own official URL,

and separately generates hreflang + x-default.

We’ll go into this in more detail in the International SEO section later.

Canonicals are important, but don’t hand every URL problem to the canonical.

For example:

So a canonical is one canonicalization tool, not a cure-all for a site’s duplicate content problems.

Company websites should watch out for:

What all these problems have in common is that the site isn’t telling search engines clearly and consistently which URL is the official version.

When a search engine crawls a URL, the site returns not only content but also an HTTP status code.

It tells browsers and search engines what the result of this URL request was.

The statuses technical SEO runs into most often are:

These status codes aren’t an “SEO score” in themselves, but they affect how search engines understand and handle URLs.

200 OK means: the server successfully returned this page.

Official public pages should normally return 200.

But 200 ≠ Google will definitely index it.

For example, even if a page returns 200, it may still:

So what an HTTP status code deals with is the state of the URL request.

It doesn’t directly decide search rankings or indexing outcomes.

When a URL has changed permanently, you can use a permanent redirect.

For example, the original URL: /seo-guide-old

now has the official URL: /seo-guide

When users or search engines visit the old URL:

Old URL → Permanent Redirect → New URL

This makes it clear that: this resource has permanently moved to a new URL.

Common permanent redirect statuses include 301 and 308.

Both express a permanent redirect; the difference mainly concerns how the HTTP request method is handled.

For a typical SEO URL migration, what really matters is whether the site uses the correct permanent redirect and whether the destination makes sense.

Suppose a business has an article that has existed for two years:

/seo-guide becomes /resources/seo-guide after a redesign.

If you simply delete the old URL: /seo-guide → 404

then:

may all lead to a page that doesn’t exist.

If the new page really does replace the old content, the more sensible approach is usually:

Old URL → Permanent Redirect → New URL

This is a very important part of an SEO migration.

When the slug of an article, product, or category is changed, our platform automatically records the old slug and creates a 308 Permanent Redirect to the new official URL.

Old-to-new URL relationships that can be determined clearly like this are well suited to being handled automatically by the system.

If a URL change is only temporary, you can use a temporary redirect.

Common ones include 302 and 307.

For example, if a page temporarily needs to point to another URL for a campaign or maintenance, but the original URL is expected to come back, a temporary redirect may be used.

So don’t simply follow the rule: “always use 301 for redirects.”

Instead, first decide whether this URL change is permanent or temporary.

404 Not Found means the server can’t find a resource for this URL.

Many businesses see 404s in Search Console and think “the site has an SEO problem; every 404 has to be fixed.”

That’s not actually the case.

If a page:

then returning a 404 is perfectly reasonable.

What really needs fixing is important pages unexpectedly turning into 404s.

For example:

These are the situations worth checking first.

This is another common practice during site redesigns.

After finding lots of old URLs that no longer exist, a site simply sets:

All 404s → Homepage

It seems like “at least users won’t see an error page.”

But the problem is:

the original /old-product-a

may have nothing to do with the homepage’s content.

A sensible redirect should be: old content → the new content that truly corresponds to it.

If there’s no reasonable replacement page at all: letting it return a normal 404 or 410

is usually clearer.

So the core of redirects isn’t “never let a 404 appear.”

It’s “whether there’s really a reasonable correspondence between the old and new URLs.”

410 Gone means: this resource may have existed before, but it has now been explicitly removed.

Its meaning is slightly different from 404:

For deleted articles and products, our platform can return a genuine 410 Gone

instead of replacing it with a 200 OK page that merely looks like an error page.

This brings up another important issue: soft 404s.

Suppose a user visits a page that doesn’t exist.

The screen shows “This page can’t be found.”

But the server actually returns 200 OK.

This can create a soft 404.

In other words, the content looks like it doesn’t exist, but the HTTP response tells search engines the page is fine.

So technical SEO shouldn’t just check “whether the screen shows a 404.”

You also need to confirm whether the HTTP status code the server actually returns is correct.

5xx means a problem has occurred on the server side.

For example:

An occasional, brief server error doesn’t mean the site’s SEO will immediately take a major hit.

But if Googlebot keeps running into 5xx errors over a long period or across lots of crawling, it means search engines can’t reliably get the site’s content.

What really needs fixing at that point is:

not the SEO of your articles.

Suppose:

URL A

↓

URL B

↓

URL C

↓

URL D

This forms a redirect chain.

If URLs keep changing over a long period, this kind of situation builds up easily.

The better approach is: A → D

Have old URLs redirect directly to the final official version wherever possible.

Our platform’s slug redirect mechanism looks up the final destination to reduce the chance of creating redirect chains.

This is also why URL management isn’t just: “as long as there’s a redirect, it’s fine.”

You also need to check: where the redirect ultimately leads.

You can start with this simple principle:

What really matters is:

Not finding ways to make every page return 200 for the sake of SEO.

Yes, but first we need to clear up a very common misconception:

So it can’t be simplified to:

What really deserves attention with site performance is whether pages are fast, stable, and offer a good interactive experience when users actually browse the site.

Google uses Core Web Vitals to measure several important aspects of a site’s user experience.

There are currently three main ones:

Measures how long it takes for the main content to load.

For example, in the hero section of a company website:

can become the page's LCP element.

Google recommends an LCP of 2.5 seconds or less for a good experience.

Measures how quickly the page responds visually after a user interacts with it.

For example:

If heavy JavaScript work is blocking the browser, the page can still feel sluggish and laggy to use, even after it has finished loading.

Google recommends an INP of 200ms or less.

Measures visual stability while the page is loading.

For example, a user is about to click a button when an image suddenly loads and pushes the whole screen down.

That is a layout shift.

Google recommends a CLS of 0.1 or less.

So Core Web Vitals can be summed up simply as:

PageSpeed Insights is very useful, but the most common mistake companies make is treating the Lighthouse Performance Score as an SEO KPI.

Say a site currently scores 92

and, chasing a score of 100,

the team starts:

In the end it invests heavily without any noticeable improvement in real user experience or business results.

A more sensible priority is to fix the issues that actually affect user experience and Core Web Vitals first,

rather than chasing a perfect score in a testing tool.

This is another important concept when using PageSpeed Insights.

Website performance data falls roughly into two kinds:

PageSpeed Insights / Lighthouse help developers find performance problems, but real users may differ in:

So if a site has enough data, its Core Web Vitals real-user data (Field Data) is well worth looking at.

A company should not run one test on its own computer, get Performance 95,

and conclude that every user is having a great experience on the site.

Business websites very often use a large hero image.

And hero images easily become the LCP element.

If that image:

it can directly hurt LCP.

That is why our platform currently raises the loading priority of the first hero image on the home page, while other images keep lazy loading so they don't all download at once. The platform also uses the Next.js Image Optimizer to serve WebP / AVIF, responsive images, and size information.

The principle behind this is not "give every image priority."

It is:

Common sources of CLS include:

For example, if an image provides its width / height up front,

the browser can reserve the space in advance.

Our platform's image handling also provides size information, reducing the chance of layout shifts after images load.

So many performance problems are not something you start solving by installing a "speed-up tool" after the site is finished.

They should be considered at the site architecture and component design stage.

Modern business websites easily end up adding:

Every additional script can add to the work the browser has to do.

So technical SEO and performance optimization can't stop at whether images are compressed.

You also need to check how much JavaScript the site actually loads, and whether all of it is really necessary.

This is also where INP needs particular attention.

A more accurate way to understand it:

Google uses Core Web Vitals in its ranking systems, but Google also states clearly that good Core Web Vitals do not guarantee a page will rank higher.

That's because Google Search ranking considers many other signals as well.

For example:

Compare two articles:

You can't conclude from this that B will definitely rank higher.

So companies shouldn't turn technical SEO into "the faster the site → the better the SEO, guaranteed."

The more reasonable view is: a site should provide a good page experience, but content relevance and quality remain the core of search strategy.

Companies don't need to chase "PageSpeed 100 across the entire site."

A more reasonable approach is:

This is far more in line with a company's real cost-effectiveness

than pouring unlimited engineering time into SEO tool scores.

Using JavaScript technologies such as React, Next.js, or Vue does not in itself mean a site's SEO will be worse.

What you really need to confirm is:

So the core question of JavaScript SEO is not: "Does the site use JavaScript?"

It is: "Which important content depends on JavaScript, and can search engines reliably get that content?"

With a traditional website, when a search engine requests a page, the server usually returns HTML that already contains the main content.

For example:

When Googlebot fetches the HTML, it can see the main content right away.

But with some client-side rendering sites, the HTML returned the first time may contain only:

It then has to:

Download JavaScript → Execute JavaScript → Fetch data → Build the DOM

before the real content appears.

Google can process JavaScript, but this adds rendering

as one more step to consider.

From an SEO perspective, you can start with a simple understanding of three approaches.

The server first provides a basic page structure.

The browser then runs JavaScript to generate the main content.

The flow looks roughly like:

HTML Shell → JavaScript → API / Data → Content

If your main SEO content relies entirely on CSR, you need to check carefully that search engines can render it properly.

When a user or search engine requests a page, the server first generates HTML that contains the main content.

So the initial response can already include:

JavaScript then takes over the site's interactivity.

The page's HTML is created ahead of time, at build or another generation stage.

When a search engine or user visits the site, they get the already-built page content directly.

You can't judge it that simply.

What really matters is whether the final site lets Google properly get its important content.

Google can render JavaScript, so CSR ≠ no SEO.

Likewise, SSR ≠ automatically better SEO.

If an SSR site has:

it will still have SEO problems.

So rendering strategy is one of the foundations of technical SEO,

not a search ranking trick.

For public pages with search value, you should especially confirm whether:

can be reliably fetched by search engines.

Purely interactive features, such as:

usually don't all need server rendering for SEO.

This is also why modern websites so often use a server + client hybrid architecture.

The TimTech platform currently uses Next.js App Router.

The main content of public pages is handled mostly by Server Components, for example:

While:

and other interactive features are handled by Client Components.

Based on a review of the current implementation, even with JavaScript disabled the main text content is still present in the HTML.

The principle behind this is not "the less JavaScript, the better."

It is letting JavaScript handle what genuinely needs interaction, and not making important search content depend entirely on client-side rendering when there's no need to.

Another common problem with JavaScript websites: something looks clickable on screen, but search engines don't necessarily see a normal link.

For example, if important navigation is only a JavaScript onclick event

with no real, parseable href, it can affect how search engines discover pages.

So the more sensible approach for important internal links is still to provide a normal:

Modern frameworks can use their own routing components, but they should still end up producing links that search engines can understand.

Our platform's main navigation, footer, and article and content links use Next.js <Link> or <a href> rather than relying only on JavaScript events for navigation.

SPAs or client-side navigation can create another kind of problem.

When a user clicks, the site doesn't do a traditional full-page reload; instead JavaScript switches the route → updates the content.

That in itself is fine.

But you still need to make sure each URL has the correct:

It can't be that the on-screen content changed, but the page information search engines see didn't change correctly.

So JavaScript SEO can't stop at checking "Can Google see the text?"

You also need to check whether every indexable URL truly represents a complete and correct page.

Companies don't necessarily need to study their website framework themselves.

The more practical check is what did Google actually get?

For example, you can use URL Inspection in Google Search Console to see a page's indexing and crawling status.

On the engineering side, you can further confirm:

That is far more meaningful than simply asking: "Is our site built on Next.js?"

Structured Data is a way of describing page content in a standardized format, making it easier for search engines to understand what the information on this page represents.

For example, a page mentions TimTech

Search engines can understand it from the text, but with structured data the site can state more explicitly that this is an Organization.

Likewise:

These schema types help search engines understand a page's content and entities.

When talking about structured data, you'll usually run into two terms:

For example, an article might include:

This isn't writing a separate article for Google; it's describing, in a structured way, information that already exists on the page.

Its main value is: helping Google understand page content more explicitly, and giving eligible content the chance to use specific search appearances.

For example, Google supports search features for different types of structured data.

But there are two very important concepts here:

Even if the schema is completely correct, Google still decides for itself whether and how to show it in search results.

So you shouldn't treat structured data as "an SEO trick that raises rankings once you add it."

This is one of the most important principles of implementing structured data.

For example, if a product page doesn't actually show a price,

you shouldn't generate something arbitrary just to make the Product schema look complete:

Because 0

means the product is free.

It doesn't mean contact us for a quote.

Our platform has exactly this real-world situation.

If a product has an actual price, its Product structured data can generate the corresponding Offer.

But if a product uses quote-request mode

and has no real price, the platform won't generate a fake Offer just to fill out the schema.

This principle actually matters more than "the more complete the schema, the better."

Another important principle: don't describe content in structured data that users can't actually see or that doesn't exist on the page.

For example, if a page has no:

but you add this information to the JSON-LD just hoping for better search appearance, that isn't a reasonable approach.

The role of structured data should be describing the page's content,

not creating a separate set of content that only search engines can see.

Not every site needs every schema.

It should be decided based on the actual page content.

Our platform currently supports, by page type:

So the sensible approach isn't stuffing every schema into every page.

It's providing the structured data that matches what the page actually is.

If a business website has 300 articles + 500 products

asking content editors to write JSON-LD by hand every time they publish clearly isn't sustainable in the long run.

The more sensible approach is:

CMS Content

↓

Page type

↓

The system generates the corresponding structured data

For example, when an article is published, the system already knows its:

so it can use this existing data to generate Article structured data.

Our platform takes this approach too, automatically generating the corresponding JSON-LD from page data and CMS content.

This reduces the risk of the on-screen content being updated while the structured data is forgotten.

This follows the same principle as canonical, covered earlier.

Suppose the official URL is: https://example.com/zh-TW/product-a

but the structured data uses: https://example.com/product-a

and the latter also redirects.

It may still be understood in the end, but there's really no need for the site to create this inconsistency.

So the better practice is for:

to all use the final, official public URL wherever possible.

Our platform follows this principle as well.

FAQPage used to be a very popular SEO structured data type.

But companies shouldn't, just because "FAQ schema can take up more space in search results,"

create FAQs in bulk.

Google has already limited where FAQ rich results are shown; they now mainly apply to eligible, well-known government and health websites.

So business articles can still include FAQs that are genuinely helpful.

But don't treat FAQ Schema as a sure way for an ordinary business website to get FAQ rich results.

This shows once again: the value of structured data is first and foremost describing content correctly, not chasing SERP effects.

Once structured data is in place, you can use Google's Rich Results Test

to check whether Google-supported structured data has:

You can also view some structured data / search appearance reports in Search Console.

But passing the test still only means the technical format meets the relevant requirements.

It doesn't mean Google will definitely show a rich result.

Google Search Console isn't just for checking keywords, impressions, clicks, and rankings.

For technical SEO, one of its more important uses is:

Because the site's code "looking correctly configured" doesn't mean Google's actual processing will match expectations.

So a technical SEO check can't stop at the site's admin; you also need to go back to Search Console to see what Google actually sees.

Start by looking at: Indexing → Pages

Here you can see the site pages Google knows about, along with statuses such as:

and others.

But when you see Not indexed , don't immediately assume "the site's SEO has a problem."

Because some pages shouldn't be indexed in the first place.

For example:

What you really need to confirm is:

If you find that an important page isn't showing up in Google Search, you can use URL Inspection to look at that specific URL.

For example: https://example.com/technical-seo

You can confirm:

This is especially important for technical SEO.

For example, the site clearly sets Canonical → URL A

but Search Console shows Google-selected Canonical → URL B

That means it's worth digging further: why did Google decide B is the main version?

Under Indexing → Sitemaps you can submit a sitemap, for example: https://example.com/sitemap.xml

and confirm whether Google can read it properly.

If there's a problem with the sitemap, you can further check:

But keep in mind: Sitemap Success ≠ all URLs are indexed.

The Sitemap report and the Page Indexing report should be read together.

Search Console also provides a Core Web Vitals report.

It helps companies see whether the site has:

judged by Core Web Vitals metrics such as:

to assess the actual user experience.

A very important point here: Search Console's Core Web Vitals use real user data, not the result of a single Lighthouse test.

So if a PageSpeed Insights lab test looks great but Search Console still shows many Poor URLs, it's worth investigating the problems real users are running into.

Search Console can also help you see how Google judges the site's HTTPS status.

A normal business website should make sure its main official pages are served over HTTPS .

If the site exists at both http://example.com and https://example.com

you should also set up a consistent official version and redirects.

On our platform, TLS / SSL for custom domains is handled by Vercel, and HTTP also redirects to HTTPS.

So handling it at the implementation level is one thing; Search Console lets you verify it again from the site status Google actually sees .

If the site uses Google-supported structured data, Search Console may provide related reports.

They can help you find:

But again, don't take no rich result to mean the structured data is wrong.

Correct structured data only means the page meets one of the relevant technical conditions; whether and how it ultimately appears in search results is still up to Google.

A technical SEO audit can easily turn into see red → fix everything.

But that isn't the most efficient approach.

For example:

A site has 500 404s , which looks like a lot.

But if they are all:

the priority may not be that high.

Conversely, if there's just 1 important service page set to noindex

it's only one, but the business impact could be huge.

So technical SEO priorities should be based on:

not simply which report has the most errors.

Companies don't need to check every report every day.

You can start in this order:

This is far more efficient than aimlessly browsing every Search Console report.

A website redesign is a stage where technical SEO is especially prone to problems.

Because a redesign usually isn't just "giving the site a new design."

It may also change, at the same time:

If these aren't handled together, you may find the new site launched fine, but the search traffic it had built up starts to drop.

So when a site with existing SEO traffic is redesigned, technical SEO should be treated as formal migration work, not something patched in after launch.

This is one of the most common problems in a website redesign.

For example, the old site had: /blog/seo-guide

The new site changes it to: /resources/seo-guide

If the old URL simply disappears, old URL → 404

then everything that pointed to the old URL:

will break.

If the new page genuinely replaces the old one, you should set up: old URL → Permanent Redirect → new URL

And the redirect should ideally point straight to the final URL, avoiding A → B → C

and similar unnecessary redirect chains.

During a redesign, some teams deal with large numbers of old URLs quickly by simply sending all old URLs → Homepage

That isn't a good migration strategy.

For example: /products/machine-a

If the product no longer exists and the new site has no corresponding content, redirecting it to the home page doesn't really answer:

"Where has this old page moved to now?"

The more sensible approach is:

Redirects should establish a genuine old-to-new mapping between pieces of content,

not simply eliminate every 404.

During a redesign, it's easy to migrate only the content you can see on screen,

and forget the original page's:

For example, the old site had already set a different SEO title for each service page.

but after the new site launched, every one of them became Company Name | Official Website

That isn't a design problem; it means the SEO metadata migration wasn't completed.

So before a redesign goes live, you should first inventory the old site's important SEO data, then confirm it has been migrated correctly to the new site.

Once the site architecture changes, canonicals need to be rechecked as well.

Common mistakes include:

In particular, the staging domain carried over into the live site

is well worth checking during a site migration.

After launch, confirm: Canonical → official domain + final official URL

rather than only confirming that pages open normally.

During development, to keep the test site from being indexed by Google, you might use noindex

or other crawling / indexing restrictions.

That's perfectly reasonable.

What's truly dangerous is forgetting to remove them after launch.

The result is a site that looks like:

but its important pages are still telling search engines not to index them.

So your launch checklist should always include rechecking robots.txt, robots meta, and the actual indexing settings.

After a redesign, the sitemap should reflect the new live site.

For example, it shouldn't keep including:

At the same time, the new:

should also appear in the sitemap as expected.

If the sitemap is generated automatically by the CMS from live content, these problems are usually easier to control.

Our platform generates the sitemap dynamically from content that is published and allowed to be indexed, and uses the official canonical URLs.

Even if you've already set up Old URL → Redirect → New URL

the site's internal links still shouldn't rely on redirects in the long run.

For example, article A still links to: /old-seo-guide

It may eventually redirect to: /seo-guide

but the cleaner approach is still: update the internal link directly to /seo-guide.

So after a site migration is done, you should crawl the site again and check for:

to make sure the site's own internal linking already uses the new official URLs.

Sometimes a redesign doesn't delete any content, and the URLs don't change either.

But the site's navigation structure changes dramatically.

For example, it used to be: Home → Service page

After the redesign it becomes: Home → Solutions → Industry → Category → Service page

Important pages become harder for users and search engines to find.

So a migration isn't just URL mapping.

You also need to recheck the site's information architecture and internal linking.

In particular, important pages that had search traffic and business value shouldn't suddenly become hard-to-find, isolated content after a redesign.

A site might move from WordPress

to React / Next.js / Headless CMS

or the other way around.

Even if the design and content are exactly the same, the way search engines get the content may have changed.

You need to reconfirm:

So:

"Google could index the old site" doesn't let you conclude "the new site has the same content, so it'll definitely be fine."

After the rendering architecture changes, it still needs to be validated again.

Redesigns of international websites need particular care.

For example, the old site used:

and it changes to:

Beyond redirects, this also involves:

If you just move the pages over without rebuilding the relationships between language versions, international SEO problems can arise.

If the existing site already has SEO traffic, we don't recommend:

Finish the new site → launch → discover 404s → only then start adding redirects.

The more sensible approach is to organize this before launch:

Old URL

↓

New URL

↓

Action

For example:

This URL mapping can serve as the core reference for the migration.

Based on the platform's current implementation, the system can already handle:

So beyond the system automatically handling content slug changes, site administrators can also use the Redirect Manager to manage redirects for other URLs.

This is especially important for redesigns.

For example, when a company migrates from an old site to the new platform, it can first build a URL mapping of old site URL → new site URL , then set up permanent redirects for the old URLs that need to be kept.

Even so, although the platform has a Redirect Manager, if the existing site has built up a lot of search traffic, we still don't recommend simply moving the site over.

The more complete process should still be old site URL audit → URL mapping → redirect setup → new site launch → Search Console / crawl validation

Because the Redirect Manager solves "how to carry out redirects," while which old URLs should point to which new URLs still has to be judged based on the actual content and its SEO value.

Technical SEO problems are often not "no SEO was done at all," but rather:

The site already has settings such as a sitemap, canonicals, robots.txt, and structured data, but those settings conflict with one another.

So the point of a technical SEO audit isn't simply confirming "Does this feature exist?"

It's confirming "Is it set up correctly, and is it consistent with the site's other SEO signals?"

Below are the technical SEO problems most common on business websites, and the ones most worth checking first.

One of the most serious situations is when important content on the live site is blocked by robots.txt.

For example:

If this rule appears on the live site, it's effectively asking search engines not to crawl the entire site.

Another situation is less obvious:

but /products/ happens to be the company's most important product content.

So whenever a site launches, is redesigned, or has its robots.txt adjusted,

you should reconfirm afterwards that important pages are still allowed to be crawled.

Another common problem is an important page that browses normally but is set to noindex.

Users usually can't notice this problem at all.

The site:

But search engines receive an instruction not to add this page to the index .

Especially when moving from staging to production, check whether the noindex used during testing has been properly removed.

A sitemap should mainly provide the official URLs the site wants search engines to process.

So if the sitemap contains many:

that means the sitemap is inconsistent with the site's other technical SEO signals.

For example, Sitemap: this is an important URL

but Meta Robots: don't index

That's an unnecessary contradiction.

Canonical errors in automated settings can easily affect a large number of pages.

Common problems include:

So it isn't enough to confirm that the HTML "has a canonical tag."

You also need to confirm where it actually points.

After a site changes its:

if the old URLs had already built up:

simply turning them into 404s can cause an unnecessary loss of search equity.

If there's a clear correspondence between old and new content, you should set up an appropriate permanent redirect.

So a URL shouldn't be treated as a text field you can change at will.

It is itself one of the search assets a site builds up over time.

Having redirects doesn't mean they're necessarily handled well.

For example:

/page-a

↓

/page-b

↓

/page-c

↓

/page-d

This means that after several rounds of URL changes, new redirects kept getting chained onto the old rules.

A cleaner result should be, as far as possible, /page-a → /page-d

So during a URL migration, you should also regularly check whether redirects ultimately point straight to the official URL.

If a site has a large number of Internal Link → 404

it doesn't just hurt the user experience; it also means the site's own content structure has lost its consistency.

Common causes include:

So even if old URLs already have redirects, we recommend gradually updating the site's own internal links to the final official URL.

Don't rely on redirects long-term to patch up your internal site structure.

Soft 404 is an issue that's easy to overlook.

For example, the page displays "This content could not be found."

but the server actually returns: 200 OK

This can send search engines a contradictory signal: the page says the content doesn't exist, but HTTP says the page is fine.

So handling 404s isn't just about designing a nice-looking 404 page.

More importantly, the server must return the correct HTTP status code.

The common Technical SEO problem with JavaScript sites isn't "using React."

It's that important content depends entirely on client-side JavaScript, and search engines can't reliably retrieve it.

For example:

don't appear in the initial content, and rendering then fails.

So for JavaScript sites, you should actually confirm what content search engines end up retrieving.

rather than just looking at the browser and thinking "I can see it, so Google should be able to see it too."

One of the most common Structured Data mistakes is creating data that doesn't exist on the page just for the sake of Schema.

For example:

You can't judge whether this kind of issue is correct by "Schema Validation Passed."

Because a correct technical format ≠ correct data.

Structured Data must ultimately reflect what users actually see.

Another common Technical SEO misconception is pouring all engineering resources into PageSpeed Insights.

Site performance matters.

But Technical SEO also includes:

If an important service page is set to noindex:

even if PageSpeed is: 100

the real SEO problem still hasn't been solved.

So Technical SEO priorities should be set by actual search impact

not by: whichever tool's score is easiest to see.

Finally, one of the issues with the biggest impact on business websites: a redesign that handles only design and content, and not SEO Migration.

The result can be:

So if the site already has search traffic:

rather than something you start fixing after launch, once you notice traffic dropping.

Businesses don't need to tackle every issue at once as soon as they spot it.

A more sensible first question is: "Does this issue prevent important pages from being crawled or indexed?"

If yes: → Top priority.

Next, check: Does it cause widespread errors in important URLs, canonicals, redirects, or site architecture?

If yes: → Handle it first.

Only then: optimizations with smaller gains that don't directly block search engines from processing the site.

So one important service page mistakenly set to noindex

may deserve priority over 500 old 404 URLs with no value at all .

Technical SEO covers many technical details, but businesses don't need to check every item every day.

A more practical approach is to go through a fixed checklist when a site launches, during a redesign, during an SEO audit, or when you notice indexing anomalies.

The following can serve as a basic Technical SEO checklist for business websites.

There are really only two core questions:

"Can Google retrieve the important content?" and "Is the truly important content allowed to be indexed?"

For business websites on a CMS, the sitemap is best maintained automatically by the system based on actual content status, rather than by editing XML by hand.

The real goal isn't: "Every page has a canonical tag." It's "The site is consistent about which URL is official."

Besides automatic redirects on slug changes, our platform now also has a general-purpose Redirect Manager for managing other old URL → new URL redirects.

Internal linking isn't just content SEO; it's also an important foundation for how search engines understand a site's information architecture.

The point isn't:

"A site can't use JavaScript." It's "Important search content must be reliably retrievable by search engines."

More Schema isn't better.

Accuracy matters more than quantity.

The core of performance optimization is still: "improving the real user experience."

If you're redesigning an existing site, also confirm:

Finally, one thing to keep in mind:

A Technical SEO checklist is an inspection tool, not an SEO scorecard.

Different sites differ in:

— they're all different.

A 20-page corporate brand site and an ecommerce platform with tens of thousands of products naturally need different depths of Technical SEO.

So the more sensible principle remains:

The goal of Technical SEO isn't to turn every SEO audit tool green.

It's to keep the site itself from becoming an obstacle to search growth.

Technical SEO seems to involve a lot of technical jargon

but in the end all of these items come back to the same thing:

When businesses do SEO, content is still a very important core.

You need to understand:

Technical SEO doesn't replace that work.

It deals with a different question: once a business has built good content, does the site itself have the right technical foundation for that content to take part in search properly?

So Technical SEO is a technical foundation that needs ongoing maintenance along with the site.

If this foundation is built well, businesses don't need to deal with underlying issues like canonicals, sitemaps, and Structured Data all over again every time they publish an article.

and can put more time into what really matters: understanding search needs, creating expert content, improving the user experience, and continuously building up the site's search value.