Technical SEO sounds like a developer’s job, and some of it is. A surprising amount of it is checking, though, and checking only needs a browser, a login to Google Search Console and a free afternoon.
For each item you get what it is, how to check it, what good looks like, and whether fixing it is a you-job or a developer-job.
Before you start
You need three things:
- Google Search Console access. This is Google’s free dashboard showing how it sees your site. If nobody at your company has it, whoever manages your domain can verify it.
- PageSpeed Insights. A free Google page where you paste a URL and get a speed report.
- A list of your ten most important pages. Homepage, main service or product pages, contact page, and whatever brings in the most enquiries.
Keep a simple spreadsheet open with four columns: page, problem, who fixes it, done.
Can Google find and index your pages?
Indexing means Google has stored a page and can show it in results. Everything else on this list is wasted on a page that is not indexed.
Indexing. In Search Console, open the Pages report under Indexing. It shows how many pages are indexed and how many are not, with reasons. Then paste each of your ten key URLs into the URL Inspection box at the top. Good looks like every key page saying it is on Google. Some unindexed pages are normal (thank-you pages, old redirects). An important page in the “not indexed” pile, with no clear reason, goes to a developer.
Sitemap. An XML sitemap is a file listing the pages you want search engines to know about. Try yourdomain.co.uk/sitemap.xml in a browser, then check the Sitemaps report in Search Console to see whether one has been submitted and read successfully. Good looks like a submitted sitemap with a success status. Submitting it is a you-job. Fixing what is in it usually needs whoever runs the CMS (the system you edit the site in).
Robots.txt. This is a small text file telling crawlers which parts of the site to leave alone. Visit yourdomain.co.uk/robots.txt. You are looking for one thing: a line reading Disallow: / sitting under User-agent: *. That blocks the whole site, and it is commonly left behind after a redesign when the staging version goes live. Good looks like a short file blocking only admin or internal areas. Changes are a developer-job.
Check indexing first. A page Google has not indexed cannot rank for anything, however good the copy is.
Titles, descriptions and headings
Page titles. The title tag is the headline shown in search results and on the browser tab. Search site:yourdomain.co.uk in Google to see many at once. Good looks like a unique title per page, saying what the page offers and where relevant who or where it is for, short enough not to be cut off (roughly 50 to 60 characters is a sensible guide). Bad looks like “Home”, “Services”, or the company name repeated on every page.
A pattern you can lift:
[What you do] for [who] in [where] | [Brand]
Meta descriptions. The sentence or two under the title in results. Google does not use it as a ranking signal and often rewrites it, but a good one earns clicks. Aim for one or two plain sentences, up to about 155 characters, saying what the visitor gets. Missing or duplicated descriptions are a you-job in most CMSs.
Headings. Each page should have one H1 (the main on-page heading) that states the subject, with H2s dividing the page into sections in a logical order. Check by reading the page: if the biggest text says “Welcome” or “Solutions that deliver”, the H1 is wasted. Rewriting headings is a you-job. If your theme uses heading tags for styling in the wrong places, that needs a developer.
Speed and mobile
Core Web Vitals. These are Google’s three measurements of how a page feels to load and use:
| Metric | What it measures | Google’s “good” |
|---|---|---|
| LCP (Largest Contentful Paint) | How long the main content takes to appear | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How quickly the page responds when you tap or click | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How much the layout jumps about while loading | 0.1 or less |
Paste each key page into PageSpeed Insights and look at the mobile tab. Where it shows data from real users, trust that above the lab score.
Your part: oversized images. A photograph uploaded straight from a camera or a stock library is the most common cause of a slow page, and resizing and compressing images before upload is a you-job. Scripts, fonts, caching and server response time are developer-jobs, and sometimes a hosting problem.
Mobile. Google indexes the mobile version of your site, so that is the version that counts. Open your key pages on your own phone, on mobile data and not office wifi. Can you read the text without zooming, tap the menu with a thumb, and complete the enquiry form? Does a pop-up cover the screen? Content fixes are yours. Layout fixes are a developer’s.
Broken links and redirects
A broken link leads to a “page not found” (404) error. A redirect sends visitors and search engines from an old address to a new one.
To check, run a crawler. Screaming Frog is the well-known desktop tool for this and will list every link on the site with its status. Search Console’s Pages report also lists URLs returning “not found”.
Good looks like:
- No internal links pointing at missing pages.
- Old URLs that still get visits or have links from other sites redirected to the closest equivalent page, not dumped on the homepage.
- No chains, where one redirect leads to another and then another.
Fixing a link inside your own copy is a you-job. Setting up redirects depends on your CMS: some have a simple redirect screen, others need a developer.
Structured data and HTTPS
Structured data. This is labelling added to a page’s code that tells search engines what things are: this is a business, this is its address, this is a product, this is a question and its answer. It can qualify pages for enhanced listings. Check with Google’s Rich Results Test, which tells you what it found and whether there are errors. Good looks like organisation or local business details at minimum, with no errors. Some CMS plugins make this a you-job. Otherwise brief a developer.
HTTPS. The padlock. It means the connection between visitor and site is encrypted. Type your address with http:// and without www, and with it. Every variation should land on one single https:// version. Any browser warning, or a page that loads on plain http, goes to a developer or your host today, not next sprint.
Sort what you found
By now the spreadsheet has two kinds of rows.
| Usually a you-job | Usually a developer-job |
|---|---|
| Titles and meta descriptions | Unexplained indexing problems |
| Headings and page copy | Robots.txt and sitemap contents |
| Image sizes | Scripts, caching, server speed |
| Broken links in content | Redirect rules and chains |
| Submitting the sitemap | Structured data without a plugin |
| Mobile content snags | Layout, HTTPS and certificate faults |
Fix your column this week. Turn the other column into a brief with the page, the problem, and the evidence (a screenshot or the Search Console message).
If you would like a second opinion before briefing anyone, our Website Audit measures most of this from outside your site and a person checks it before it reaches you. See also how to read a website audit.