A quote lands in your inbox with a line on it that reads "Core Web Vitals remediation and schema implementation," followed by a number with a comma in it. You have no way to judge whether that is necessary work or expensive air, because nobody has explained those words in language that assumes you run a business rather than a server.
Technical SEO is the work of making sure a search engine, and a real person holding a phone, can get into your site, read it, and use it without hitting anything awkward on the way. Everything on that invoice is that same job wearing a different name, and Google gives you free tools to check each one yourself.
The one question underneath all of it
Technical SEO is not a way of tricking Google into liking you. It's plumbing. If you ran a shop, you'd care whether the front door opens and whether someone with a stroller can get down the aisle. This is the same job for a building made out of code.
The jargon, translated
| Word on the quote | What it means | How to check it yourself |
|---|---|---|
| Core Web Vitals | Google's three measurements of how a page feels to load and use | PageSpeed Insights (free; paste your address in) |
| LCP, INP, CLS | The three Vitals: how long until the main thing appears, how quickly the page reacts to a tap, whether the layout jumps while loading | Same report, one score each |
| Crawling and indexing | Google visiting your pages, then filing them so they can appear in results | Search Console, Pages report |
| robots.txt | A small file telling crawlers which parts of the site they may visit | Type yourdomain.com/robots.txt into a browser |
| noindex | A per-page instruction that says "do not list this one" | Search Console, Pages report |
| Sitemap | A file listing the pages you want found | Search Console, Sitemaps report |
| Structured data (schema) | Invisible labels saying what a piece of content is: phone number, hours, price | Google's Rich Results Test |
| HTTPS | The padlock: your site's certificate encrypting what visitors send | Check the address starts with https |
| Lazy loading | The browser waits to fetch an image until you scroll near it | PageSpeed Insights, same report |
Keep that table and you can read the next quote unaided. The rest is what each row means for the money.
Speed, and the three places it goes
People leave slow sites before they have seen a single thing you sell. A blank white screen on a phone reads as broken, and there is always another result waiting on the back button.
Photos straight off a phone or a camera. Your phone takes a picture big enough to print on the side of a bus, and every visitor downloads that poster to look at it at the size of a playing card. Google's image guidance says images "are often the largest contributor to overall page size, which can make pages slow and expensive to load." The fix is unglamorous. Resize each image to about the size it appears at, save it in a modern format (WebP is one Google Search supports), and lazy-load the ones lower down the page.
Too many small errands. Every plugin, tracking pixel, chat widget and custom font is a separate thing the browser has to fetch before the page feels finished. If you have a live chat box nobody staffs and two analytics tools you don't read, that is free speed sitting there.
Hosting at the bottom of the market. The cheapest hosting tiers put your site on a machine shared with other sites, at the mercy of whichever neighbour is having a busy morning. Ask your host what the next tier costs before you pay a developer to shave bytes off a page.
"Core Web Vitals" is Google's name for measuring how all of that felt to the visitor: "a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page." web.dev's published targets are an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, measured at the 75th percentile of page loads. PageSpeed Insights is free, you paste your address in, and it tells you which of the three is hurting.
Does your site actually work on a phone
Looking fine on a phone and working on a phone are different tests, and the second one is where the money leaks out. Google "uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking." The phone version of your site is the one Google reads.
The phone version of your site is the one Google reads.
The things that pass a glance and fail in a thumb are small. Buttons set close enough together that ordering the wrong thing is a coin flip. Body text small enough that a reader over forty has to pinch and zoom to see your prices. And the classic, a contact form with the Submit button hiding off the right edge of the screen.
There is a test for this that costs nothing but your own phone. Get off your Wi-Fi so you are on mobile data like a customer, and try to do the main thing your site is for. Notice anywhere you have to concentrate, because a stranger won't. If the site passes and the calls still aren't coming, the problem is on the page rather than under it, and the website conversion guide covers that.
Can Google find your pages at all
This is the failure that costs the most and gets noticed the least. A site that has quietly dropped out of search looks completely normal when you visit it yourself.
Broken links. Internal ones especially. A link to a page you deleted or renamed is a door in your hallway that opens onto a brick wall. Google's documentation says a "not found" URL is removed "from the index if it was previously indexed." A free link checker, a tool that walks your site the way a crawler does, will list every one.
Pages accidentally shut out of search. robots.txt "tells search engine crawlers which URLs the crawler can access on your site." noindex is a per-page rule, and when Google finds it, it "will drop that page entirely from Google Search results". The trap is that Google says robots.txt "is not a mechanism for keeping a web page out of Google". For noindex to work, "the page or resource must not be blocked by a robots.txt file." Block a page with robots.txt and Google can't read the noindex you put on it.
The way a whole site vanishes is simpler. A developer blocks it while building it, the site launches, and the sign stays on the door. In WordPress that sign is a checkbox on the Reading settings screen worded "Discourage search engines from indexing this site". Since WordPress 5.3 it adds a noindex tag to the site's pages. It is the first thing I check on any WordPress site I am handed.
A sitemap that exists and is current. Your platform may generate one. The part worth verifying is that it updates when you add a page, and that it isn't still listing pages you removed two years ago. Google is candid about the limits: a sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed." Google's sitemap page also says a site of about 500 pages or fewer that is "comprehensively linked internally" may not need one at all.
While you're in there, set up Google Search Console. Its index report shows "all the pages Google indexed or tried to index in your website". If Google finds new issues, "you'll receive an email from Search Console alerting you." It is free, and it is the one place Google tells you directly.
What you can check yourself before paying anyone
- Paste your address into PageSpeed Insights and note which of the three Vitals is red
- Do the main task on your own phone, on mobile data
- Type yourdomain.com/robots.txt into a browser and read what it blocks
- In WordPress, open Settings, then Reading, and confirm the "discourage" box is unticked
- Set up Search Console and read the Pages report once
- Load your homepage and confirm the address starts with https
Schema, in one paragraph
Structured data, also called schema, is labelling. When you pack a moving box you can write "kitchen, glasses, fragile" on the side, or leave it blank and hope. Schema is writing on the box. Google calls it "a standardized format for providing information about a page and classifying the page content", so Google can show your phone number and hours directly in results instead of guessing.
One honest caveat. Google's wording is that structured data "can enable search results that are more engaging to users," which it calls rich results. Can enable, not will. Check what your platform already outputs with Google's Rich Results Test before anyone bills you to build it from scratch. For a local business, the labels that matter most match your Google Business Profile, which the local SEO guide walks through.
Security you can see from the outside
Your address should start with https, and the padlock should be there. That is the site's certificate doing its job: proving the site is who it claims to be and encrypting what visitors type into it. Google lists "Are your pages served in a secure fashion?" among its own page experience questions. The plainer reason is that a browser meets an uncertified site with a full-screen warning, and nobody reads a red warning and decides to keep shopping.
Certificates expire and are meant to renew on their own. When a renewal quietly fails, your site is fine on Monday and terrifying on Tuesday. Put a monthly reminder in to load your own homepage in a browser you don't normally use. That is the whole maintenance routine.
Common questions
Will fixing my Core Web Vitals move me up the rankings? Maybe a little, and Google won't promise it. Its page-experience page says "Core Web Vitals are used by our ranking systems", and a few lines later that good scores in a report don't "guarantee that your pages will rank at the top of Google Search results". Fix speed for the customer about to leave; the ranking effect is the smaller prize.
Should every image be lazy-loaded? Lazy-load the images lower down the page and let the first big one load normally. web.dev's advice is "Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images." Lazy-load the hero and you slow down the very measurement you were trying to fix.
The short version
Keep it fast and usable in one hand, and make sure nothing is quietly blocking search engines from reading it. Underneath the invoice, the work is that ordinary, the same category as wiring a building to code. PageSpeed Insights and Search Console will tell you most of it for free. Run through the list yourself before you pay anyone to run through it for you. It's the same list I use.
Checked against Google Search Central, web.dev and WordPress.org help pages on 2026-09-21: Understanding Core Web Vitals and Google search results, Web Vitals, Understanding page experience, Introduction to robots.txt, Block Search indexing with noindex, Learn about sitemaps, Introduction to structured data markup, Mobile-first indexing best practices, Get started with Search Console, Image SEO best practices, Browser-level image lazy loading, How HTTP status codes affect Google's crawlers, Settings Reading screen