To fix technical SEO issues, start with what you can see going wrong (a page missing from Google, the wrong URL ranking, errors in Search Console, a slow page) and trace it back to the cause with URL Inspection and the Page indexing report. Most problems on a small business site come down to six causes: a noindex or robots.txt block, a page Google chose not to index, duplicate URLs, broken redirects, server errors and slow pages.
Most lists of “30 technical SEO issues” give every item equal weight. That sends you chasing missing alt text while your contact page sits outside Google. This guide is organized the other way round: find your symptom, confirm the cause, apply the fix, then check that Google saw it. Every fix below comes from Google’s own Search Console and Search Central documentation, checked in November 2026.
If you want a preventive pass over a whole site instead, use our technical SEO checklist. This page is for when something is already wrong.
First, find which issue you actually have
Don’t start with a crawler or an audit score. Start with one URL you care about and ask Google what it thinks of it.
- Paste the URL into URL Inspection in Search Console (the search bar at the top). It tells you whether the URL is on Google and, if not, why.
- Read the Page indexing section. The fields that matter are “Crawl allowed?”, “Page fetch”, “Indexing allowed?”, “User-declared canonical” and “Google-selected canonical”. One of them is usually the answer.
- Run Test live URL. This checks the page as it is now, so you can see whether a fix you already made has worked. Google notes the live test only confirms that its crawler can access the page for indexing. It doesn’t promise the page will be indexed.
- Open Indexing, then Pages to see how many other URLs share the same reason. If 200 pages have the same problem, it’s a template or setting, not one page.
- Fix the cause, then validate (more on that at the end).
Step 4 is the one people skip. A noindex tag on one page is a typo. The same tag on every service page is a theme setting or an SEO plugin option, and fixing it once fixes all of them.
Symptom: a page you need isn’t in Google at all
URL Inspection says “URL is not on Google”. Check these causes in this order, because the first two are the most common and the quickest to fix.
Cause: a noindex tag or header. The Page indexing report calls this “URL marked ‘noindex’”. It often comes from a “discourage search engines” setting left on after a launch, or a plugin applied to a whole page type. Fix: remove the <meta name="robots" content="noindex"> tag or the X-Robots-Tag: noindex header, then confirm with a live test, as the Page indexing report help recommends.
Cause: blocked by robots.txt. “URL blocked by robots.txt” means a Disallow rule stops Google crawling the page. Fix: edit the rule in yoursite.com/robots.txt. If the block is deliberate, leave it.
Cause: a 404 or soft 404. A real 404 for a deleted page is fine. A “Soft 404” is a page that looks empty or says “not found” but returns a normal success code. Google’s fix is to return a real 404 for pages that are gone, or add real content to pages that should exist. Our guide on fixing 404 errors in Search Console covers which ones to redirect.
Cause: a login wall (401 or 403). Google’s crawler never sends a password, so a page that needs one can’t be indexed. This hits members’ areas and staging sites that went live with protection still on. Fix: remove the login for pages you want found.
Symptom: Google found the page but won’t index it
Two reasons in the Page indexing report look alike but mean different things.
“Crawled - currently not indexed” means Google fetched the page and decided not to index it, at least for now. Google says this is common and not always a problem. The usual cause on a small site is a page that adds little: a thin location page that repeats the homepage with a new city name, or a tag archive. Fix: make the page clearly useful on its own, merge it into a stronger page, or accept that it doesn’t need to rank. Then request indexing from URL Inspection. There’s a daily limit on those requests, so save them for pages that matter.
“Discovered - currently not indexed” means Google knows the URL but hasn’t crawled it yet. The report help says Google rescheduled the crawl because it expected crawling to overload the site. On a small site, the practical fix is to link to the page from pages Google already visits, such as your main navigation or a related service page. Our internal linking tools roundup shows how to find pages with no links pointing at them.
Symptom: Google shows the wrong URL
You search for your page and Google shows http:// instead of https://, a ?ref= version, or a different page entirely. URL Inspection shows the “User-declared canonical” and “Google-selected canonical” disagree.
Cause: duplicates with no canonical. “Duplicate without user-selected canonical” means Google found copies and picked one itself. Google says this isn’t an error. Fix: if Google picked the wrong one, add a rel="canonical" tag pointing at the version you want.
Cause: Google overruled your canonical. “Duplicate, Google chose different canonical than user” means the pages differ more than you think, or other signals point elsewhere. Google calls redirects and canonical tags strong signals and a sitemap a weak one, and they work best stacked. Fix: make your internal links, sitemap and canonical all name the same URL, and redirect true duplicates.
Don’t use robots.txt or noindex to pick between copies. Google’s duplicate URL guide warns against both: a robots.txt block can still leave the URL indexed without its content, and noindex removes the page from Search entirely.
Symptom: redirects that fail or don’t pass the page on
The Page indexing report shows “Redirect error” when a chain is too long, loops, or ends at a bad or empty URL. Google’s crawlers follow up to 10 redirect hops by default, but every extra hop is another place for something to break, and site moves tend to stack them up.
The other redirect problem doesn’t show as an error. Google’s redirects guide says permanent redirects (301 and 308) tell Google the target should be the canonical, while temporary ones (302, 303 and 307) don’t, so the old URL can stay in results. JavaScript redirects only work if Google renders the page, which can fail. Fix: use server-side 301s that go straight to the final URL, and update internal links so they skip the redirect altogether. A free crawler such as Screaming Frog shows every chain on a small site in a few minutes.
“Page with redirect” in the not indexed list is usually fine. It’s the old URL, and Google is indexing the target instead.
Symptom: pages dropping out, with server errors
A spike in “Server error (5xx)” is the one issue that can remove pages you already rank with. Google says 5xx and 429 errors make its crawlers slow down, and that indexed URLs that keep returning errors are eventually dropped.
Check Settings, then Crawl stats, and look at Host status. It shows failures fetching robots.txt, DNS problems and times the server didn’t respond. Google’s Crawl Stats help says sites under about a thousand pages rarely need this report, so only open it when you see server errors. The fixes are usually with your host: an overloaded shared plan, a firewall or bot protection blocking Googlebot, or a plugin that crashes under load.
Symptom: a page is in Google that you wanted out
“Indexed, though blocked by robots.txt” trips up a lot of people. Robots.txt stops crawling, not indexing, so Google can still index a blocked URL from links pointing to it. Worse, Google’s noindex guide says a noindex tag only works if the page is not blocked by robots.txt, because otherwise the crawler never sees it.
Fix: remove the robots.txt block, add noindex, and let Google recrawl. Once the page has dropped out, you can block it again if you need to save crawling, though small sites rarely need to.
Symptom: slow pages, or “poor” in Core Web Vitals
The Core Web Vitals report uses data from real Chrome visitors and groups similar URLs together, so one bad template shows up as dozens of pages. The thresholds are:
- LCP (how fast the main content loads): good at 2.5 seconds or less, poor above 4 seconds.
- INP (how fast the page reacts to taps and clicks): good at 200 milliseconds or less, poor above 500.
- CLS (how much the layout jumps): good at 0.1 or less, poor above 0.25.
A group’s status is set by its worst metric. Small sites often see no data at all, because a group needs a minimum number of visits. In that case, test your top pages in PageSpeed Insights instead. The usual fixes are oversized images for LCP, missing image width and height for CLS, and chat widgets or old tracking scripts for INP. The checklist’s speed section goes through them.
Issues you can safely ignore on a small site
Some things look alarming and aren’t:
- “Alternate page with proper canonical tag.” Google says no action is needed. The page points to its main version correctly.
- 404s for pages you deleted on purpose with no replacement.
- Crawl budget. Google’s crawl budget guide is aimed at sites with more than a million pages, or 10,000 pages that change daily. If new pages get crawled the day you publish them, you don’t need it.
- Not every URL being indexed. The Page indexing help says plainly that you shouldn’t expect every URL on your site to be indexed. Judge the report by whether your important pages are in.
- Audit tool scores. A score of 71 out of 100 from a crawler doesn’t map to anything Google measures. Use crawlers to find chains and broken links, not to grade the site.
How to confirm Google saw the fix
Once every affected URL is fixed, open the issue in the Page indexing report and click Validate fix. Google rechecks the URLs and emails you the result. The help page says this typically takes up to about two weeks, sometimes longer. If it fails, See details shows which URL still has the problem.
Core Web Vitals work differently. Start tracking begins a 28-day monitoring window, and the issue only counts as fixed if no URL shows it during that time. Starting it doesn’t make Google recrawl anything.
FAQ
How do I check my site for technical SEO issues for free?
Verify the site in Google Search Console and read the Page indexing and Core Web Vitals reports, then inspect your most important URLs one by one. Add a free crawler, such as the free version of Screaming Frog (up to 500 URLs), to find redirect chains and broken internal links.
Can ChatGPT do a technical SEO audit?
It can explain an error message or review a robots.txt file you paste in, but it can’t see your Search Console data or tell you whether Google has indexed a page. Use it to understand findings, and use Search Console and a crawler to find them.
How often should I check for technical SEO issues?
Glance at the Page indexing report once a month, and inspect key pages after any redesign, plugin change, hosting move or new site launch, since that’s when most noindex tags, blocks and redirect chains appear.
Fix the page you need, then let the rest wait
Most technical SEO issues only matter when they touch a page you need customers to find. Pick your five most important URLs, run each one through URL Inspection, and fix whatever stands between them and “URL is on Google” before you touch anything else. A clean report full of unimportant pages is worth less than one service page that’s indexed and loads fast.
For the wider sweep once those are fixed, work through the technical SEO checklist, and if a page with structured data is among your five, test it with the tools in our schema markup testing guide.
