Technical SEO sounds bigger than it really is.

At the basic level, it is about making pages easier for search engines to crawl, understand, preview, and index correctly.

That does not mean tricks. It does not mean stuffing keywords into every corner of the page. It does not mean trying to outsmart search engines.

For developers, technical SEO is mostly web hygiene.

A page should have a clear title. It should have a useful description. It should say which URL is the main version of the page. It should say whether the page should be indexed. Important public URLs should appear in a sitemap.

That is the foundation.

It is not glamorous, but it matters.

Technical SEO Is Not Magic

Search engines are good at discovering and interpreting pages, but they still need clear signals.

They need to understand:

• what the page is about
• what title should appear in search
• what summary might help users understand the page
• which URL is the preferred version
• whether the page should be indexed
• where important URLs can be discovered

Technical SEO helps answer those questions.

It does not guarantee rankings. It does not replace good content. It does not make a thin page useful. But without the technical foundation, even good content can become harder to understand, harder to preview, or harder to index correctly.

That is why developers should care about it.

Not because SEO is magic, but because HTML output, URLs, metadata, and sitemaps are part of the website.

Titles: The Page’s Search Result Headline

The <title> element is one of the simplest and most important parts of technical SEO.

It sits in the HTML <head> and gives the page a title that browsers, search engines, and link previews can use.

A good title should be specific, readable, and connected to the actual page content.

Bad:

<title>Home</title>

Better:

<title>BadGames — Games, Web Tools And Experiments</title>

Bad:

<title>Article</title>

Better:

<title>Technical SEO For Developers: Titles, Meta, Canonicals And Sitemaps</title>

A title should not be a pile of keywords. It should not be misleading. It should not be reused across every page.

The developer rule is simple:

Every indexable page should generate one clear, unique title.

That title should match the visible page topic. If the page heading says one thing and the <title> says another, search engines may decide that the title is not reliable.

A useful title usually includes:

• the specific page topic
• the site or brand name where useful
• enough context to make the result understandable
• no unnecessary keyword stuffing

For most pages, clear beats clever.

Meta Descriptions: The Search Result Pitch

The meta description does not usually appear on the page itself. It appears in the HTML and may be used as the search result snippet.

Example:

<meta name="description" content="A developer-focused guide to technical SEO basics: page titles, meta descriptions, canonical URLs, robots meta tags, and XML sitemaps.">

A good meta description is not just a shorter title. It should summarize why the page exists and what the visitor will get from it.

Bad:

<meta name="description" content="SEO, technical SEO, title, meta, canonical, sitemap, WordPress, plugin, ranking">

Better:

<meta name="description" content="Learn the technical SEO basics developers should get right: titles, meta descriptions, canonicals, robots meta tags, and sitemaps.">

Search engines may choose a different snippet from the page content if that better matches the user’s search. That is fine. The meta description is not a command. It is a helpful suggestion.

The important thing is to avoid empty, duplicated, or keyword-stuffed descriptions.

For developers, this means descriptions should be generated from real content fields, not from generic fallback text used everywhere.

A good meta description should be:

• page-specific
• human-readable
• accurate
• short enough to work as a search snippet
• written for users, not just crawlers

If a site has many pages, descriptions can be generated automatically. But they should still describe the actual page.

Canonicals: Choosing The Preferred URL

Many websites accidentally create multiple URLs for the same or similar content.

For example:

https://example.com/article/
https://example.com/article/?utm_source=newsletter
https://www.example.com/article/
https://example.com/article

To a user, these may feel like the same page. To a search engine, they are different URLs.

A canonical tag tells search engines which URL we prefer.

Example:

<link rel="canonical" href="https://example.com/article/">

This is useful for:

• duplicate pages
• URL parameters
• tracking links
• print versions
• archive pagination
• HTTP and HTTPS cleanup
• www and non-www consistency
• content that appears in more than one place

Canonicals are not magic. Search engines can still choose a different canonical if the signals conflict. But a clean canonical tag is a strong signal.

The developer rule is:

The canonical URL should be the clean, public, preferred URL for the current content.

Do not point every page to the homepage.

Do not output canonicals with tracking parameters.

Do not canonicalize a page to another page unless that other page is actually the preferred version.

Do not let staging, preview, or temporary URLs become canonical.

A good canonical system should be boring. Most normal pages should simply point to their own clean public URL.

Robots Meta: Should This Page Be Indexed?

Not every page should appear in search.

Some pages are useful for users but not useful as search results. Some pages are temporary. Some pages are internal. Some pages are thin until they are improved.

Examples might include:

• internal test pages
• search result pages
• temporary diagnostics pages
• thin taxonomy archives
• private utility pages
• duplicate listing pages
• low-value filtered views

That is where robots meta tags are useful.

Example:

<meta name="robots" content="noindex, nofollow">

Or, more commonly:

<meta name="robots" content="noindex">

A noindex directive tells search engines not to show the page in search results.

This is different from robots.txt.

A common mistake is thinking that blocking a URL in robots.txt is the same as noindexing it. It is not. If a crawler is blocked from accessing the page, it may not be able to see the page-level noindex tag.

For HTML pages, use robots meta when the question is:

Should this page be indexed?

Use robots.txt when the question is more about crawler access and crawl behavior.

For developers, the practical rule is:

If the page should not appear in search, make sure search engines can access the page and see a noindex directive, or remove/redirect the URL properly.

Also, do not include noindex pages in the sitemap. That sends mixed signals.

Sitemaps: The URLs We Want Discovered

An XML sitemap is a machine-readable list of URLs that the site wants search engines to discover.

Example:

<url>
  <loc>https://example.com/articles/technical-seo-for-developers/</loc>
  <lastmod>2026-06-24</lastmod>
</url>

A sitemap does not force indexing. It is a discovery signal.

A good sitemap should contain canonical, public, indexable URLs.

That means it should usually exclude:

• noindex pages
• private pages
• admin pages
• duplicate URLs
• search result pages
• thin internal utility pages
• parameter-heavy versions of the same content

Sitemaps become especially useful when a site has many pages, content types, archives, or pages that are not always linked from the main navigation.

For WordPress sites, sitemaps are often generated automatically. But automatic does not always mean correct.

Developers still need to decide which content belongs in the sitemap.

For example:

• Should posts be included?
• Should pages be included?
• Should tools be included?
• Should experiments be included?
• Should categories be included?
• Should tags be included?
• Should custom taxonomies be included?
• Should author archives be included?
• Should noindex content be excluded?

The answer depends on the site.

A sitemap should reflect the site’s real indexing strategy, not just dump every possible URL into a file.

The Signals Should Agree

Technical SEO is strongest when the signals agree.

An indexable article should usually have:

• a clear title
• a useful meta description
• a self-referencing canonical URL
• an indexable robots state
• a place in the sitemap
• internal links from relevant pages

A noindex test page should usually have:

• a useful internal title
• a robots noindex directive
• no sitemap entry
• no accidental promotion from public navigation

A duplicate or alternate URL should usually have:

• a canonical pointing to the preferred URL
• internal links pointing to the preferred URL
• no sitemap entry unless it is the canonical version

The problems usually start when signals disagree.

For example:

• A page says noindex but appears in the sitemap.
• A canonical points to one URL, but internal links point to another.
• The title says one topic, but the visible heading says another.
• The sitemap includes archive pages that the site does not actually want indexed.
• The homepage, articles, tools, and experiments all reuse the same meta description.
• Tracking parameters appear in canonical URLs.
• Thin archive pages are indexable before they have useful content.

Technical SEO is not about adding more tags.

It is about making the signals consistent.

WordPress Makes This Both Easier And Easier To Get Wrong

WordPress is good at generating pages. That is also why technical SEO needs care.

A WordPress site can have posts, pages, categories, tags, custom post types, custom taxonomies, author archives, date archives, search pages, feeds, pagination, attachment pages, and plugin-generated URLs.

That is a lot of URL surface.

Some of those URLs are useful public pages.

Some are not.

The developer job is to decide what deserves to be indexed and what should stay out of search.

For a small site, this can be simple. For a content-heavy site with tools, experiments, articles, and custom content types, it becomes more important.

The question is not:

“How do we index everything?”

The better question is:

“What should search engines see as useful public content?”

That question should drive titles, descriptions, canonicals, robots rules, and sitemaps.

A Developer Checklist

For every public page type, ask:

• Does it output exactly one clear <title>?
• Does the title match the visible page topic?
• Does it have a useful meta description?
• Is the canonical URL clean and correct?
• Should this page be indexed?
• If it should be noindex, is that explicit?
• If it is noindex, is it excluded from the sitemap?
• If it is indexable, is it included in the sitemap when appropriate?
• Does the sitemap only contain canonical public URLs?
• Do archive pages have enough content to deserve indexing?
• Are search pages, test pages, and diagnostics pages kept out of the index?
• Are Open Graph and social metadata aligned with the page title and description?

This checklist is not exciting, but it prevents many avoidable problems.

A Simple Technical SEO Policy

A useful technical SEO policy can be short.

For example:

Index pages that are useful public destinations.

Noindex pages that are internal, temporary, duplicated, thin, or not useful as search results.

Include only canonical, indexable public URLs in sitemaps.

Write titles for humans first.

Write descriptions that explain the page clearly.

Keep canonical URLs clean.

Avoid metadata bloat.

Test the output.

That is enough for many sites.

Why We Care About This

We like small, useful web systems.

That also applies to SEO.

A site does not always need a huge SEO plugin with every possible feature enabled. Sometimes it needs a small, first-party SEO layer that outputs the right metadata, respects WordPress core systems, keeps sitemaps clean, and avoids unnecessary frontend bloat.

That is the kind of technical SEO we care about.

Not magic.

Not tricks.

Not dashboards for the sake of dashboards.

Just clean output, correct signals, and pages that search engines and humans can understand.

Technical SEO is the quiet layer under the content. When it works, nobody notices it. When it is missing or inconsistent, everything becomes harder.

So we build it properly.

More from BadGames

Read the latest game development articles.

Browse practical notes on browser libraries, production choices, game business, careers, and the decisions behind playable work.

Open Blog

Aug 7, 2026

WebGPU Reaches Mainstream Runtimes, but Discovery Remains the Real Bottleneck

The BadGames Report looks at Phaser 4.3 WebGPU, Godot 4.8 texture streaming, Steam demo algorithm updates, instant web…

Read article

Jul 17, 2026

AI Can Build a Tiny MMO, but It Cannot Maintain an Engine

The BadGames Report looks at PointlessQuest, Godot's AI contribution problem, engine maintenance updates, browser-game tooling and indie platform…

Read article

Jul 2, 2026

What Is On-Page SEO and How Do You Do It?

Learn how to optimize your web pages for better search visibility. Discover the essential elements of on-page SEO,…

Read article