What is technical SEO? It is the unglamorous layer under the words: whether a crawler can reach the URL, whether that URL is the one that gets indexed, and whether the template actually shows the content. Crawl the templates that generate the pages, not only the homepage. When something is wrong, name the URL that shows it, and write the fix as a task a developer can ship. None of that promises a ranking.
Takeaways
- Start with the templates that build the pages, not with a homepage screenshot.
- A finding without a URL is not a finding you can hand to a developer.
- Check fetch, then indexation, then whether the fetched HTML contains the words.
- Canonicals and redirects are how duplicate addresses get consolidated. They are not a content strategy.
- If the page fetches cleanly and still says the wrong thing, the next job is the copy, not another crawl tool.
What Technical SEO Is For
People ask what technical SEO is after someone says the site is "not technical enough" and hands them a tool export. The export is a list. The work is smaller than the list.
A search engine has to request a URL, receive a page, and decide whether that address is the one to keep. If the request fails, if the HTML is empty, or if several addresses all claim to be the same page, the words you wrote are not in the running. Technical SEO is finding which of those is true, on the URLs that matter, and removing what is in the way.
Technical SEO describes it the same way: crawl paths, index bloat, broken templates, and pages that load in a way that hides the content. The output is a fix a developer can ship, not a slide.
Search Engine Optimization also includes what the page says, whether the local profile matches, and whether another site would cite you. Technical work is the part that asks a prior question: can the page be seen at all?
You do not need a new vocabulary for this. Fetch, status, index, canonical, redirect, template. If a recommendation does not use those words and a URL, ask for the URL before you accept the task.
Look at the structure that holds the page up before you repaint it.
Crawl the Templates, Not Only the Homepage
The homepage is one URL. The pages a customer needs are usually built by a template: a service layout, a location layout, a post layout. A crawl that only loads the homepage will report that the site is fine while every service URL shares a broken heading, a missing main column, or a canonical that points home.
Crawl a sample of each template. Include a page you know should rank, a page that was published recently, and a page that is older and might have been forgotten. You are looking for a pattern. One broken URL can be a typo. The same break on every URL from one template is the template.
A practical pass looks like this:
- List the templates that generate real pages, not the marketing names of your menus.
- Fetch two or three URLs from each template the way a crawler would, and save the HTML.
- Note the status code, the final address after redirects, and whether the main heading is in that HTML.
- If a whole template fails the same way, write one task that names the template and an example URL.
- Leave one-off typos for a second pass. They are real, and they are not the pattern.
Index bloat is the other side of the same crawl. Tag pages, internal search results, and parameter URLs can be fetched by the thousand. They are not what you want kept. Seeing them in a crawl is useful. "Optimizing" each one is not. Decide which templates deserve to be indexed, and keep the rest from competing.
Indexation, Canonicals, and Redirects
Fetched is not the same as indexed. A URL can return a page and still be excluded, duplicated, or pointed elsewhere. Look at three things, in this order, and attach each note to a URL.
First, can the request succeed? A 404, a 500, or a redirect that never ends is a broken path. Write down the address you requested and the address you landed on.
Second, is this the address that should be kept? The same content often lives at more than one URL: with and without a trailing slash, with a tracking parameter, or on both a www host and a bare host. A canonical is the signal that says which address should represent the set. Google's documentation on consolidating duplicate URLs is the primary description of that signal. Read it before you invent a rule. A canonical does not fix a redirect loop, and a redirect does not choose a search query.
Third, does the HTML contain the page you think you published? If the visitor sees a heading and the fetched source does not, the index can only keep what was fetched.
| What you see | What it usually means | The task to write |
|---|---|---|
| Request never settles | A redirect loop or a chain that should have been one hop | Name the start URL and the hop that repeats |
| Two URLs, same page | Duplicates with no chosen address | Pick the URL to keep, then canonical or redirect the other |
| Canonical points at the homepage | Every page is telling the crawler that home is the real copy | Correct the template so each URL canonicals to itself, unless it is a true duplicate |
| Page looks right in the browser, empty in the fetch | The template paints the content after the response, or hides it from the HTML | Change the template so the words are in the response |
| Thousands of filter URLs in the crawl | Index bloat from a template you did not mean to expose | Stop those URLs from being crawled or indexed, in the template |
Each row is a task with an example URL. A report that says "improve canonicals" without an address is a slide. Send it back.
A task a developer can ship is specific enough to finish in one change. "On the service template, every URL canonicals to the homepage. Example: the service URL you just fetched. Point the canonical at that URL's own address. Done when a second fetch of the same URL shows the canonical matching the address in the browser." That is one task. "Review canonicals sitewide" is a project with no end, and it hides the template that is actually wrong.
While you are on that URL, look at whether a rule is keeping the crawler out. A disallow in the site's robots file, or a noindex on a template you meant to keep, will make the rest of the checks moot. Name the rule and the URL it blocks. Removing a block you did not mean to set is often a smaller change than a redesign, and it belongs in the same short list.
Templates That Hide the Content
Some pages look finished in a browser and arrive empty, or nearly empty, in the response a crawler stores. The heading was drawn by a script after the document loaded. The main column is a placeholder. The useful paragraph sits in a tab that the HTML never includes.
This is a template problem. Buying a faster host does not put the paragraph into the response. Neither does a plugin that scores the page you see on screen. Compare the screen with the fetched HTML for one real URL. If the sentence you care about is missing from the fetch, that is the bug.
Broken templates show up in smaller ways too. Every service page shares one title. The main heading is an image with no text. The content that should be in the HTML is only in a PDF. A crawler can be told about images, and a person can open a PDF, but the ordinary case is simpler: the words belong in the page.
Write the fix the way you would write any other development task. Which template. Which URL proves it. What the response should contain when the task is done. "Make the site more technical" is not a task.
How to Keep a Technical SEO Checklist Short
"Technical seo checklist" is a popular search, and the useful checklist is the table above plus the template crawl. Fetch, final URL, index decision, words present in the HTML. Run it on the templates that matter.
Longer checklists add items that are sometimes relevant and often not: a score for every image, a warning for every redirect that is actually fine, a demand that every page carry the same markup. Those items feel like work. They bury the URL that returns a 500.
"Technical seo audit" is a related search, and it is a different job. An audit looks at the site as it is, including this layer and the pages that matter commercially, and it ends in a short list ranked by what blocks the next improvement. SEO Audits is that deliverable. This article is the explanation of the technical layer, not the audit itself.
Searches for a technical SEO service or a consultant are hiring searches. They fit a service page. They do not need a second explainer.
When the Problem Is the Copy
If the URL fetches, the canonical is itself, the redirect is a single hop to the address you wanted, and the heading is in the HTML, technical SEO has done the part it can do. A page can still be the wrong page. The title describes a different offer than the heading. Two URLs want the same search. The first screen is a banner with no statement.
That is On-Page SEO: one query theme per URL, then a title, a heading, and a first screen that agree. Rewriting copy on a URL that is not in the index wastes the rewrite. Crawling a site whose pages already fetch cleanly, and calling every thin paragraph a technical defect, wastes the crawl.
Stop when you can name the next task in one sentence. Either a developer changes a template, with a URL as proof, or a writer changes what a specific URL says. If you cannot tell which sentence it is, you do not have a finding yet.
Questions
Is Technical SEO the Same as an Audit?
No. Technical SEO is the layer: crawl paths, indexation, canonicals, redirects, and templates that hide content. An audit is a look at the site as it is, covering that layer and the pages that matter, and it ends in a short list in an order you can act on. You can fix a known technical issue without commissioning a full audit.
Do I Need a New Site to Fix a Crawl Problem?
Usually not. Most crawl and index problems sit in a template, a redirect, a canonical, or a rule that blocks a folder. Name the URL that shows the problem and write the fix as a task. A new site is a different project, and it can carry the same template mistake with it.
How a Canonical Names the URL
A canonical is a signal about which URL should represent a set of duplicates. Use it when the same content is reachable at more than one address. It does not repair a redirect loop, and it does not choose a query for the page. Google's own documentation describes how duplicate URLs are consolidated.
Can a Fast Host Fix a Hidden Template?
No. A faster response does not help if the words are missing from the HTML the crawler receives. Check the fetched version of a real URL. If the heading the visitor sees is not in that fetch, the template is the problem, not the host's speed claim.
Why Does Technical SEO Matter?
Because a better sentence never gets read if the crawler cannot fetch it. Titles, headings, and mentions all assume the URL resolves to the page you think it does.
How Do You Do Technical SEO?
Name the URL that fails. Say whether the failure is a redirect, a hidden template, or two addresses for one page. Write the fix as a task a developer can ship, then fetch the URL again.
What Is a Technical SEO Audit?
A look at whether the templates and the URLs can be fetched and indexed, written as a short list in an order. It is not the whole of technical SEO, and it is not a promise that the list will move a ranking.
Conclusion
Technical SEO asks whether the important URLs can be fetched, kept, and read. Crawl the templates, attach every finding to a URL, and write the fix as a task. When the fetch is clean and the page still says the wrong thing, stop crawling and fix the words.
If you want crawl, index, and template issues written as tasks a developer can ship, Speak With Us.
