Technical SEO for people who are not developers

Technical SEO has a reputation problem. The phrase suggests server configuration, log file analysis and rendering pipelines, and so non-technical owners assume the whole area is closed to them and skip it entirely.

That is expensive, because the technical problems that actually stop sites ranking are not exotic. They are a short list of specific, findable failures, and almost all of them are visible through free tools that require no code. The exotic end exists, but it matters on sites with hundreds of thousands of pages, not on a site with forty.

This is a sub-pillar of technical SEO. Here we are only interested in what a non-developer can find and, in most cases, fix.

The only question technical SEO answers

Everything below reduces to one thing: can Google reach, read, and index your pages, and does the result work for a person on a phone?

That is it. Technical SEO does not make a page rank. It removes the reasons a page cannot rank. Those are different jobs, and confusing them is why people spend weeks on site speed when their real problem is that the page answers the wrong question.

So the correct posture is: find the blockers, fix them, and then go back to the work that actually moves things.

Start with the one report that matters

Google Search Console's Pages report tells you which of your pages are indexed and, for the ones that are not, why. It is free, it comes from Google directly, and it is the single most useful technical diagnostic that exists.

If you have not set it up, do that first. Everything else in this article is guesswork by comparison.

Read it in one specific way: compare the number of indexed pages with the number of pages you think you have. If you have published forty pages and eleven are indexed, you have a technical problem and the report will name it. If thirty-nine of forty are indexed, your ranking problem is not technical and you should stop reading and go work on content.

The reasons it gives are plain English. The ones you will actually encounter:

| What it says | What it means | Serious? | |---|---|---| | Excluded by 'noindex' tag | Your page tells Google not to index it | Yes, if unintended | | Blocked by robots.txt | Google is not allowed to fetch it | Yes, if unintended | | Alternate page with proper canonical tag | Google chose a different URL as primary | Usually fine | | Duplicate without user-selected canonical | Google found several near-identical pages | Sometimes | | Crawled — currently not indexed | Google looked and chose not to index | Often a content problem | | Discovered — currently not indexed | Google knows it exists but has not fetched it | Usually patience | | Soft 404 | The page looks empty or error-like | Yes | | Not found (404) | The page is gone | Depends |

Two of these deserve special attention, because they are the ones people misread.

"Crawled — currently not indexed" is not usually a technical fault. Google fetched the page, understood it, and decided it was not worth indexing. That is a content judgement, not a crawling failure. Fixing your sitemap will not change it. Writing a page that is genuinely worth indexing will.

"Discovered — currently not indexed" on a new site usually means wait. Google knows the URL exists and has not got round to it. On a site with no external links and no history, this can persist for weeks and is normal.

The four things that silently block everything

These are the failures that make a site invisible while everything looks fine to you. Each takes two minutes to check.

1. A stray noindex tag

The most damaging single thing that can happen to a site, and it happens constantly — usually because a staging site was launched with its "discourage search engines" setting still on, or a template applied a noindex rule to a whole section.

How to check without code: open your page in a browser, view source (Ctrl+U), and search for noindex. If it appears in a meta robots tag, that page is telling Google to stay away.

Faster: Search Console's URL Inspection tool on any page tells you directly whether indexing is allowed.

How to fix: on WordPress, Settings → Reading → uncheck "Discourage search engines". On other platforms, look for a "search engine visibility" or "SEO" toggle. If a plugin is applying it, the plugin's settings will say so.

2. A robots.txt that blocks too much

robots.txt sits at yourdomain.com/robots.txt and tells crawlers what they may fetch. Type that URL into your browser right now and read it.

What you are looking for is a line saying Disallow: / — which blocks the entire site — or a Disallow: rule covering a section you want indexed.

The common cause is the same as above: a rule appropriate for a staging site that came along to production.

One important distinction that trips people up: robots.txt controls crawling, not indexing. Blocking a page in robots.txt does not reliably remove it from search results — Google may still index it from other signals while being unable to read it, which produces the worst of both. To keep a page out of the index, use a noindex tag and let Google crawl it. Google's documentation is explicit about this and it is the single most misunderstood point in the whole area.

3. The site is not actually reachable

Obvious in principle, invisible in practice, because you are logged in and cached and everything looks fine to you.

How to check: open your homepage in a private/incognito window. Then try it on mobile data with wi-fi off. Then check that both yourdomain.com and www.yourdomain.com load, and that http:// redirects to https://.

If your site is served on both www and non-www without a redirect, you have effectively two copies of every page. Pick one, redirect the other. Your host or platform has a setting for this.

4. Nothing links to the page

Not usually filed under technical, but mechanically it belongs here: a page linked from nothing is discovered only through your sitemap, and sitemap-only discovery is slow and weakly prioritised.

If a page matters, something should link to it. The system for that is internal linking.

Speed, in proportion

Site speed is the most over-discussed item in technical SEO relative to how often it is the reason a page is not ranking.

The honest position: speed is a real factor and it is rarely the deciding one. A slow page that is the best answer will outrank a fast page that is not. But a page slow enough to annoy people loses visitors regardless of position, and that is the better reason to care.

How to check: run your page through Google's PageSpeed Insights. Read the field data at the top if it appears — that is what real visitors experienced. The lab score below it is a simulation and people fixate on it far more than it deserves.

What a non-developer can actually fix, in order of return:

1. Oversized images. By far the commonest cause. A 4MB photo scaled down in the browser still downloads 4MB. Resize before uploading; most images need to be no more than about 1,600 pixels wide.
2. Too many plugins. Every one adds code to every page. Deactivate and delete what you do not use — deactivating alone is not enough on some platforms.
3. No caching. A caching plugin or your host's caching setting is usually a single toggle and often the biggest single improvement.
4. Heavy third-party scripts. Chat widgets, multiple analytics tools, embedded feeds, ad scripts. Each has a cost. Remove the ones nobody uses.
5. A slow host. If the server takes over a second to respond before anything else happens, no amount of front-end tuning fixes it. This is a moving-house problem, not a tuning problem.

Everything past that list — code splitting, critical CSS, font loading strategy — needs a developer and delivers less than the five items above.

Mobile

Google indexes the mobile version of your site. If your mobile version is missing content the desktop version has, the missing content effectively does not exist.

How to check: open your site on an actual phone. Not a resized browser window — a phone. Then check:

• Does everything on desktop also appear here?
• Can you tap buttons without hitting the wrong one?
• Can you read the text without zooming?
• Do pop-ups cover the content?

That last one matters more than people think. An interstitial that covers the page as soon as a search visitor arrives is a specific, named problem in Google's guidance, and it is also simply hostile.

Duplicate content, which is less scary than it sounds

There is no penalty for duplicate content in the way people imagine. What actually happens is more mundane: Google picks one version to show and the others are set aside. The problem is when Google picks a version you did not want, or when your own pages split their signals across several URLs.

The versions that occur accidentally:

• www and non-www (covered above)
• http and https
• URLs with and without a trailing slash
• URLs with tracking parameters appended
• Printable versions of pages
• Product pages reachable through several category paths

For most small sites, the first three are the entire problem and a redirect fixes them. For ecommerce, canonical tags handle the rest — Google's documentation on consolidating duplicate URLs covers the mechanics, and your platform almost certainly sets them automatically.

Where duplication is genuinely worth worrying about is when two of *your own* pages target the same query. That is a content structure problem rather than a technical one, and it is covered in keyword cannibalisation.

Structured data, briefly

Structured data is a standardised description of what a page contains, added in a script tag, that can make your result eligible for enhanced displays — review stars, FAQ expansions, event details, recipe cards.

Two honest points:

It does not improve ranking. It can improve appearance, and appearance affects clicks.

Eligibility is not entitlement. Adding markup makes you eligible for a rich result; Google decides whether to show one.

For most sites the useful set is small: organisation details on the homepage, local business details if you have a location, article markup on articles, product markup if you sell things. Every major platform has a plugin that does this without code. Test the output with Google's Rich Results Test, and do not spend a week on it.

An honest order of operations

If you do this once, do it in this order and stop when the list stops producing findings.

1. Set up Search Console. Check the Pages report.
2. Confirm your important pages are indexed. Investigate any that are not.
3. Check for stray noindex tags and an over-broad robots.txt.
4. Confirm one canonical domain with redirects from the others.
5. Open the site on a real phone.
6. Compress your images.
7. Turn on caching.
8. Check that nothing important is orphaned.
9. Stop.

That list catches the overwhelming majority of technical problems on sites under a few hundred pages. Beyond it, the returns fall off steeply, and the effort is better spent on whether your pages are the best answer to the questions you are targeting.

The full-site version of this pass, including the non-technical parts, is in how to run an SEO audit on your own site in an afternoon. If the audit comes back clean and pages still are not ranking, the problem is competitive rather than technical, and why your website is not ranking works through what is left.

What technical SEO cannot do

It removes obstacles. It does not create demand for your page.

A perfectly indexed, fast, mobile-friendly page that answers a question worse than the ten pages above it will not rank, and no further technical work changes that. Once the blockers are gone, the remaining problem is either the content or the competitive position — and where the competitive position is the honest answer and the timeline is short, buying placement outright is the alternative, with current prices visible on the rankings board.

Common questions

Do I need an XML sitemap? It helps discovery, particularly on new sites. Every major platform generates one automatically. Submit it in Search Console and move on.

How often should I check this? Once when you set the site up, then whenever you change platform, theme, or host. Those three events cause most sudden technical failures.

My developer says the site is fine — is that enough? Ask them to show you the Search Console Pages report. "Fine" and "indexed" are different claims.

Does hosting location matter for ranking? Marginally, through speed. Serving Indian visitors from a server in India is faster than from Oregon. It is not a ranking factor in itself.