Loading content
TECHNICAL SEO
Improve the technical health of your website so search engines can crawl, understand, and index your important pages while users get a faster, clearer experience.
FOUNDATION
Technical SEO is about making a website easier for search engines to access, process, and understand — and easier for people to use. It is not about manipulating search systems.
I treat technical SEO as the layer under content and links: can important URLs be fetched, rendered, and considered for search, without hiding the useful page behind a broken template or a leftover staging rule? Background on crawl, render, and index is also on my technical SEO expertise page; this solution page is the practical service framing.
Whether search engines can request important URLs without being blocked by robots.txt, auth walls, or broken paths.
Whether those URLs are allowed to be stored and considered for search — noindex, canonicals, and status codes matter here.
How folders, navigation, and URL hierarchy show what is important and how pages relate.
How people and crawlers move between related pages, including commercial URLs that sit deep in the site.
How quickly useful content appears and how stable the layout feels while it loads.
Whether the phone experience is complete — content, navigation, and tap targets — not a cut-down version of desktop.
A consistent encrypted site, working HTTP-to-HTTPS redirects, and mixed-content issues that break resources.
Which URL should represent a page when filters, parameters, or copies exist.
A list of URLs you want discovered, kept in sync with live, indexable canonicals.
Crawl hints at the host level. It does not remove a URL from the index by itself.
Markup that describes visible content so systems can understand entities, products, or articles — where it is appropriate.
Whether important copy, links, and metadata exist in a form crawlers can process, not only after a delayed client render.
IMPACT
Fixing technical issues does not automatically guarantee higher rankings. It creates a stronger foundation for search visibility and a clearer site for users.
If important URLs cannot be requested, they cannot compete. Budget on large sites is finite.
Crawl without index eligibility means the page is known but not a candidate to show.
Orphan pages and weak internal links slow discovery even when robots allow the URL.
Technical barriers can hide otherwise useful pages. Fixes do not guarantee higher rankings.
Broken links, slow templates, and confusing navigation affect people first.
Heavy scripts and unoptimized media delay useful content, especially on mobile networks.
Clear URLs, sitemaps, and status codes make later content and development work safer.
Small template mistakes multiply across thousands of URLs. Architecture and crawl efficiency matter more.
AUDIT
An audit should explain why each finding matters — not dump every crawl warning at equal weight.
Search systems need a working path to important URLs.
Access is not the same as being eligible to appear in search.
Structure tells people and crawlers what matters.
A sitemap should match the site you want discovered.
Mixed hosts and broken certificates confuse users and crawlers.
Each class of code sends a different signal.
ACCESS
Crawling means search engines can access URLs. Indexing means they can process those URLs and potentially include them in search.
A business owner can think of it as: can the door be opened (crawl), and is the page allowed into the catalogue (index)? A locked door and a “do not list this” sign are different problems. Related symptoms are covered under technical SEO issues.
The crawler is asked not to fetch the URL. That is not the same as noindex.
The URL may be crawled, then asked not to be indexed.
Signals can consolidate the wrong URL, including a homepage dump.
Crawlers follow links. 404s waste paths that used to work.
URLs with no internal links are harder to discover and maintain.
Extra hops slow crawl and can leave the intended URL under-crawled.
5xx responses can cause retries or temporary drop-off from crawl.
Blocked CSS or JS can change how a page is understood if rendering depends on them.
STRUCTURE
Internal links should be useful to people first. They also help search engines discover pages and understand relationships — not as a ranking trick.
A logical structure helps users navigate, helps crawlers find important pages, and makes page relationships clearer. Authority can flow through internal links when those links are genuine paths people would follow.
PERFORMANCE
Core Web Vitals help describe page experience. Improving them alone does not guarantee better rankings.
How soon the main visible content appears. Large images and slow servers often delay it.
How quickly the page responds after a tap or click. Heavy main-thread JavaScript is a common cause.
How much the layout jumps while loading. Unsized images and late ads often cause it.
Field data in Search Console and lab tools both have a place. Work on images, JavaScript, CSS, caching, and server response time where they affect real users. See poor Core Web Vitals if performance is already a known problem.
MOBILE
The mobile version should be a complete, usable experience — not a stripped desktop leftover.
URL SIGNALS
Canonical tags are signals, not absolute commands in every situation. Duplicate technical URL variations still confuse crawl and reporting.
The preferred address for a piece of content when more than one URL could show it.
Trailing slashes, HTTP vs HTTPS, www vs non-www, parameters, and printer-friendly copies can look like separate pages.
A live canonical page usually points at itself so the signal is clear.
Sometimes used when content is republished. They are still signals, and they must match a real preferred URL.
Pointing at staging, paginated dumps, or a generic homepage can consolidate the wrong URL.
Sort and session parameters often should not be treated as unique indexable pages.
CRAWL HINTS
A sitemap is a list of URLs you want discovered. Include live, canonical, generally indexable URLs. Do not blindly list parameter junk, noindex pages, or 404s. Example: /products/blue-kettle belongs; ?sort=price&session=abc usually does not.
It controls crawl fetching suggestions. It does not reliably control indexing. Blocking /cart from crawl is different from placing noindex on a page you still allow to be fetched. A common mistake is Disallowing CSS or JS that the renderer needs, or leaving a staging Disallow on production.
RENDERING
JavaScript websites are not automatically bad for SEO. The question is whether search engines can access, render, understand, and index important content and links.
Content may appear only after JavaScript runs. If that fails or is delayed, crawlers may see less than users.
HTML can include the important copy and links in the first response.
Pages built ahead of time often give crawlers a complete document, if the build includes the right content.
The question is what is in the document search systems can process — not which framework you chose.
Tabs, infinite scroll, and gated widgets can hide copy and links unless they are also available without extra clicks.
Links in the rendered DOM, titles, and canonicals still need to be present and consistent.
MEANING
Schema.org markup can help search engines understand content. It can make pages eligible for certain search features. It does not guarantee rich results or rankings. Do not add misleading markup.
Markup should match what is visible on the page. Validate with testing tools after template changes. Types I review when they fit the page include:
CATALOGUES
Scale is the difference: filters and templates can create more URLs than the business intends to rank.
Catalogue SEO also depends on merchandising and content. For that layer, see e-commerce SEO.
Stable, crawlable paths for items and collections, without unnecessary duplicates.
Color, size, and price URLs can explode into millions of combinations. Decide which facets deserve indexation.
Category page 2 and beyond still need a crawl path. Rel-next/prev is historical; clear links and unique value matter more.
The same product on multiple paths, or out-of-stock templates that 200 with thin content, need a consistent rule.
Canonicals should match the preferred product URL. Markup should match visible price, name, and availability.
Product sitemaps should stay current. Categories and related products should link to items you want discovered.
SCALE
Publishing, e-commerce, multi-location, and international sites share the same constraint: crawl and indexation cannot treat every URL as equal.
MARKETS
International SEO needs correct implementation — not only translated pages.
URL design, hreflang, and canonicals have to agree. Broader market strategy is on international SEO.
AFTER A MOVE
A launch is not finished when the design looks right. Technical signals on the live host still need a pass.
Planning the move — URL mapping, redirects, baseline — is covered in website migration SEO. After go-live, I still check the list below against important URLs.
ISSUES
What it is, why it matters, and what to check.
The crawler is told not to fetch them. Check Disallow rules against the URLs that earn demand.
Staging or template noindex on production. Check HTML and HTTP headers on key URLs.
Signals may consolidate the wrong URL. Compare canonical to the live address you want.
People and crawlers hit 404s. Recrawl after template or CMS changes.
No internal links. Discovery depends on sitemaps or external links. Add useful links or drop the URL.
Extra hops waste crawl. Flatten to one relevant destination.
Two URLs point at each other. Neither is a stable landing page. Test before launch.
Linked or indexed URLs missing. Fix the link, restore the page, or redirect if there is a replacement.
The server failed. Crawl may back off. Check hosting, timeouts, and error rates.
Near-identical pages compete. Prefer one canonical URL and consistent internal links.
Discovery of new or deep URLs is slower. Publish live canonicals.
Important pages sit many clicks deep. Review navigation and internal links.
Users leave; crawlers may fetch fewer URLs. Measure server time, images, and scripts.
Page experience issues on real devices. Improve LCP, INP, and CLS where field data shows a problem. That alone does not guarantee rankings.
Tiny targets, overlapping content, or missing copy on phones. Test the real mobile layout.
Markup that does not match the page can be ignored or cause manual issues. Validate against visible content.
Important copy or links missing from the processed HTML. Compare source, rendered DOM, and a crawl.
noindex, Disallow, or passwords copied live. Treat production config as separate.
PROCESS
A practical sequence. I do not invent client counts, rankings, or revenue outcomes.
Step 1
Markets, important URLs, and what “working” means before any crawl dump.
Step 2
Status codes, indexability, canonicals, sitemaps, and templates — plus Search Console where access exists.
Step 3
Separate noise from problems that affect crawl, index, or important pages.
Step 4
A blocked checkout template outranks a cosmetic 404 on an unused blog tag.
Step 5
Owners, sequence, and what “done” looks like for developers and content teams.
Step 6
Clear tickets and checks — I do not claim to replace your engineering team.
Step 7
Recrawl, headers, and live URLs — not only a staging screenshot.
Step 8
New templates, parameters, and migrations reintroduce issues. Rankings are not the only measure.
MODERN SEARCH
Technical SEO remains a foundation for visibility, including modern AI-assisted search experiences. There are no special ranking hacks, no guaranteed AI Overviews or ChatGPT citations, and no requirement for an llms.txt file for Google Search.
FIT
MEASUREMENT
Rankings and traffic should be evaluated alongside technical improvements — not used as the only measure of technical SEO quality. Temporary fluctuations happen.
FAQ
Direct answers about crawl, index, canonicals, sitemaps, speed, JavaScript, and structured data — without guaranteed rankings or traffic.
It is the work of helping search engines crawl, understand, and index important pages, and of keeping the site usable and reasonably fast for people. It is not a set of tricks to manipulate rankings.
Typically crawlability, indexability, architecture, internal links, sitemaps, robots.txt, HTTPS, status codes, canonicals, performance, mobile usability, rendering, and structured data where it is used — prioritized by impact, not dumped as a raw crawl export.
If important URLs cannot be accessed or indexed, content and links cannot help. Technical health also affects maintenance and user experience on large or frequently changing sites.
Fixing barriers can allow pages to compete that previously could not. It does not automatically raise rankings. Content, demand, and competition still matter.
After major launches, migrations, or template changes, and on a schedule that matches how often the site changes. A stable brochure site needs less frequent deep audits than a large catalogue.
Crawling is fetching the URL. Indexing is processing it and considering it for the search index. A URL can be crawled and still noindexed, or blocked from crawl entirely.
A hint for the preferred URL when similar copies exist. It is a signal, not a guarantee that other URLs will be ignored in every case.
It suggests which paths crawlers should not fetch. It does not reliably remove a URL from the index. Use noindex on a crawlable URL if you need to keep it out of the index.
A file listing URLs you want discovered. It should generally include live, canonical, indexable URLs — not every error or parameter combination.
Slow pages can hurt users and may affect crawl efficiency. Speed is one factor among many. Improving it does not guarantee better rankings.
They are useful page-experience metrics (LCP, INP, CLS). They can play a role in ranking systems as part of a broader picture. Improving them alone is not a ranking guarantee.
Yes, if important content or links only exist after a client render that crawlers do not process well. JavaScript sites are not automatically bad; implementation is the question.
Markup can help systems understand content and may make pages eligible for certain result features. It does not guarantee rich results or higher rankings. It should match visible content.
Yes. Redirects, robots, sitemaps, canonicals, indexability, and internal links should be checked on the live host. See the website migration SEO solution for planning the move itself.
NEXT STEP
Identify the technical issues that can limit crawling, indexing, performance, and search visibility—and turn them into a practical SEO improvement plan.