Technical SEO basics
Two questions come up more than all the others, usually in the same conversation. Why is the site slow, and why isn’t this page showing up anywhere. They sound like developer problems, and often they are, but the explanations stop being complicated the moment you take the vocabulary off them.
This is the plain version. No audit score out of a hundred, no colour-coded report.
Crawling and indexing are two different things
Crawling is a bot arriving at a page and reading it. Indexing is the search engine deciding to keep that page and make it eligible to appear. A page can be crawled perfectly and never indexed. That happens constantly, and it’s the most common reason something you published isn’t being found.
Things that stop the crawl: a rule in robots.txt telling bots to stay out of a directory, a page nothing links to, a login wall, or navigation that only exists once JavaScript has run. Things that stop indexing after a successful crawl: a noindex tag somebody forgot to remove, a canonical tag pointing at a different page, or the engine deciding the page is a near-duplicate of something it already holds.
Worth knowing: blocking a page in robots.txt does not remove it from the index. It stops the bot reading the page, which can leave a stale entry sitting there with no way to see the noindex you added. The two controls do different jobs and using the wrong one is a classic own goal.
A sitemap is a suggestion, not an instruction. Submitting one tells the engine your pages exist. It obliges nobody to keep them.
Why is our site slow?
Usually one of a short list, and usually not the thing people assume.
Images are the classic. A photo straight off a phone is several megabytes and gets displayed four hundred pixels wide. The browser downloads the whole thing regardless. Resizing and converting images is dull, unglamorous work and it is very often the single biggest improvement available on a small site.
Then JavaScript. Every script has to be fetched, parsed and executed before the page settles, and a page carrying a chat widget, two analytics tags, a consent banner, a review badge and a font loader is doing a lot of work that has nothing to do with why the visitor came. Third-party scripts hurt more than your own, because you don’t control how slow they are and a slow one holds up everything behind it.
Server response time comes before any of that. If the host takes most of a second to send the first byte back, nothing clever in the browser recovers it. Cheap shared hosting with a heavy CMS and a stack of plugins on top is the usual cause.
And then layout shift, which isn’t speed but feels like it. The page appears, you reach for a button, an image or a banner loads above it and shoves everything down. Reserving space for anything that loads late fixes this, and it’s a small change.
Most technical SEO advice is an undifferentiated checklist
This is the part I think is genuinely worth your time. An audit tool produces a hundred findings and presents them as a flat list sorted by a severity score the tool made up. A missing alt attribute and a site that cannot be indexed appear as neighbouring rows.
They are not the same kind of problem. A few technical faults stop a site working at all and everything else is housekeeping: worth doing when you’re already in the file, not worth a project, and definitely not worth a retainer.
Telling one list from the other is most of what Technical SEO actually involves. You can do it yourself with the split below.
Blocking faults and background noise
Blocking — the page can’t be indexed
A stray noindex, a robots.txt rule left behind from staging, a canonical pointing at something else. Nothing else you do matters while one of these is true, and none of them are visible from the front of the site. This is always the first thing to check and it takes minutes.
Blocking — the content only exists after JavaScript runs
If the server returns an empty shell and the text is assembled in the browser, you’re betting on every system that visits executing your JavaScript correctly and waiting for it. Some do. Not all of them, not always, and not the ones building answer summaries in a hurry.
Blocking — the site takes seconds to respond
Slow enough and crawlers visit less, visitors leave before anything paints, and everything downstream suffers for reasons that never show up in a report. This is a real fault, not a score to nudge upward.
Blocking — several versions of every page
The same content reachable with and without www, with and without a trailing slash, with tracking parameters bolted on, in upper and lower case. Pick one version, redirect the others to it, and state which one is canonical. Left alone this quietly splits every signal a page has.
Blocking — pages with no way in
A page nothing links to, or a menu that only renders on desktop, or a filter that generates URLs no navigation exposes. If there’s no path to a page it may as well not exist, and a sitemap entry is not a path.
Background noise — chasing a perfect speed score
Getting from a good score to a great one usually costs more than it returns. Those thresholds are a lab measurement on a simulated device. Fix the slow thing; don’t spend a week decorating the number.
Background noise — keyword density, meta keywords, heading counts
The meta keywords tag has been ignored for longer than most sites have existed. Density targets were folklore when they were invented. Two h2s in a row is not a problem and nobody is counting your headings.
Background noise — most validator warnings and alt-text audits
Write alt text, because people using screen readers need it and that’s reason enough. It is not what’s holding your rankings back. Unclosed-tag warnings from an HTML validator almost never are either.
Structured data, and why it’s worth the bother
Structured data is a small block of JSON sitting in the page that states, in a vocabulary machines already agree on, what the page is. This is a local business. Here is its address and its opening hours. This is an article, published on this date, written by this person. This is a question, and this is its answer.
The page already says all of that in words. The markup removes the guessing. That’s the entire value: instead of relying on a parser inferring correctly from your prose, you tell it directly and it stops being a judgement call. It’s also the mechanism behind rich results, the extra detail some listings show underneath the title.
It is not a ranking booster, and adding more of it does not help more. Mark up what is genuinely on the page and then stop. Describing something a visitor can’t actually see is a guidelines violation and the rich result gets withdrawn, usually without anyone telling you.
Schema generator will write the common types for you and hand back valid JSON to paste in. Meta tag & Open Graph preview shows what your title and description really look like once they’re truncated, which is shorter than most people expect. URL slug analyser handles the smaller decision of what to call the page in the address bar. All three run in your browser and nothing you type goes to a server.
Fair questions
Do we have to fix everything the audit tool flagged?
No, and trying to is a good way to spend a budget on nothing. Sort the list into faults that stop the site being found and items that are tidying. Fix the first group properly. Do the second group when you happen to be in that file anyway.
We moved the site and traffic dropped. Is that normal?
A dip after a migration is common and it is nearly always redirects. Every old URL needs to point at its specific replacement, not at the homepage. Redirecting everything to the homepage is the mistake that turns a temporary dip into a lasting hole.
Our developer says the site is fine. Who’s right?
Possibly both of you. A developer is checking whether the site works, which it may well. Whether it can be crawled, indexed and understood is a separate question, and it isn’t usually in anyone’s brief unless somebody asks for it explicitly.
How often does this need redoing?
Rarely, if it was done properly. Technical faults tend to arrive with changes: a redesign, a platform migration, a plugin, a new section of the site. Worth a look after any of those, and not much in between.
Want someone to actually look?
A technical pass finds the blocking faults first and then tells you plainly which of the rest are worth your time and which aren’t.