Technical SEO Issues: 20 Common Problems, Fixed

Technical SEO issues are problems in how a site is built or served that stop search engines from crawling, rendering, indexing or understanding its pages. Most sites have a few, and most audit reports list hundreds of warnings. The skill is telling the handful that block indexing from the long tail that barely matters, then fixing them in order.

This guide lists the 20 technical SEO issues we find most often, grouped by severity, with how to detect each and how to fix it. It is written for marketers who have an audit report in hand and developers who have to act on it. If you want the preventive version, a checklist to build against, see our technical SEO checklist for AI search; this page is the diagnostic one.

On this page

• Which technical SEO issues should you fix first?
• How do you find technical SEO issues?
• The 20 issues at a glance
• Issues that block crawling and indexing (1 to 7)
• Issues that split or waste signals (8 to 14)
• Issues that degrade experience and understanding (15 to 20)
• Warnings you can usually ignore
• Fixing technical SEO issues in the right order

Which technical SEO issues should you fix first?

Fix whatever stops Google from crawling or indexing a page before anything else, because every other improvement is wasted on a page that isn’t in the index. After that, fix the issues that split ranking signals or waste crawling, then the ones that degrade speed, mobile experience or machine understanding. The diagram shows the three tiers plus a fourth: warnings that are usually fine.

Severity is not the same as how many URLs an issue affects. A single noindex on your top service page outranks ten thousand missing alt attributes on archive images.

How do you find technical SEO issues?

Use three sources together, because each sees something the others miss:

1. Search Console shows what Google actually experienced. The Page indexing report lists why URLs aren’t indexed, the Crawl Stats report shows server responses and availability, and the Core Web Vitals report groups slow templates.
2. A crawler shows how your site is built: status codes, canonicals, redirects, internal links, duplicate titles, sitemap contents. Desktop crawlers are thorough; Screaming Frog’s documentation lists over 300 issues its tool can flag, which is exactly why you need severity tiers.
3. Server logs show every request from every bot, including AI crawlers Search Console never reports.

Group what you find by template, not by URL. Ten thousand product pages with the same problem are one fix. For a walkthrough of the Search Console side, see our Google Search Console guide.

The 20 issues at a glance

The table ranks the 20 issues we find most often, with the quickest reliable way to detect each.

Issues that block crawling and indexing (1 to 7)

These seven stop a page from reaching the index at all, so they come first.

• 1 and 2, robots.txt and noindex. The classic launch-day accident: a staging rule ships to production. Google’s help notes that robots.txt blocking doesn’t guarantee a page stays out of the index, and that to keep a page out you should allow crawling and use noindex instead. Check both files and headers after every release.
• 3, server errors. Google’s page on HTTP status codes says 5xx responses make its crawlers slow down, and URLs that “persistently return a server error” are eventually removed from the index.
• 4, robots.txt that errors. Google’s Crawl Stats help explains that if robots.txt returns a 429 or 5xx, Google stops crawling for 12 hours, then relies on the last good copy for up to 30 days. A missing file (404) is fine; a broken one isn’t.
• 5, 401 or 403 to Googlebot. Search Console’s help points out that “Googlebot never provides credentials”, so a 403 is being returned incorrectly. Common causes are geo-blocking and security plugins.
• 6, bots blocked at the edge. CDN and firewall rules can block crawlers that robots.txt allows. Check server logs for bot hits after any change to security settings.
• 7, JavaScript-only content and links. Google’s link guidance says it can reliably follow links only when they are <a> elements with an href, and its JavaScript SEO basics note that “not all bots can run JavaScript”. The detail is in JavaScript rendering and AI crawlers.

Issues that split or waste signals (8 to 14)

These don’t hide pages; they make Google choose between versions or spend its crawling on the wrong URLs.

• 8 and 9, duplicates and canonical conflicts. When http, https, www and bare-domain versions all resolve, or when your canonical tag disagrees with your links and sitemap, Google picks the version itself. Our guides to the canonical tag and duplicate content SEO cover the fixes.
• 10, redirect chains and loops. Google’s crawlers follow up to 10 hops, and the Page indexing report lists chains that are too long, loops and bad URLs in a chain as “Redirect error”. Details in redirects and SEO.
• 11, soft 404s. A page that says “not found” but returns 200. Google recommends returning a real 404 for truly missing pages, and its crawl budget guide notes that soft 404s “will continue to be crawled”.
• 12, crawl traps. Faceted navigation, calendars and session parameters that generate endless URLs. On large sites this is the main cause of real crawl budget problems.
• 13, sitemap noise. An XML sitemap that lists redirects, noindex pages or non-canonical URLs sends contradictory signals.
• 14, orphan pages. A page no internal link points to is hard for crawlers to find and gets little internal link value. Link to it from a relevant hub or category page.

Issues that degrade experience and understanding (15 to 20)

These affect how well pages perform once indexed and how accurately machines understand them. The flow below shows where each fits in a triage pass.

• 15 to 17, speed. Google’s page experience documentation says Core Web Vitals “are used by our ranking systems”, but also that relevance comes first. Fix the templates that fail in field data, starting with server response. Our guide to site speed optimization sets out the order.
• 18, mobile gaps. Google indexes the mobile version of pages. Its mobile-first indexing guidance asks that the mobile site contain the same content, headings, structured data and robots meta tags as desktop, and warns against lazy-loading primary content on user interaction.
• 19, structured data. Markup that is invalid or doesn’t match what the page shows. Validate on every key template after each release.
• 20, hreflang. Missing return tags and invalid codes on multilingual sites, covered in our hreflang guide.

Warnings you can usually ignore

A good share of any audit report is noise, and Google says so about several statuses. Its Page indexing help makes these points directly:

• “URL blocked by robots.txt” is often deliberate: “URLs blocked by robots.txt are probably intentionally blocked. Use your judgment.”
• “Not found (404)” is “not necessarily a problem, if the page has been removed without any replacement”. Redirect only if there is a real equivalent.
• “Duplicate without user-selected canonical” “is not an error, but is working as intended, because Google does not serve duplicate pages”.
• “Alternate page with proper canonical tag” means the page correctly points to an indexed canonical, “so there is nothing you need to do”.
• “Crawled, currently not indexed” needs no resubmission; Google says it “may or may not be indexed in the future”. If many important pages sit there, treat it as a content quality question.

The figure sorts the Page indexing statuses you’ll see most into the ones to act on and the ones that are usually fine.

Crawler warnings about meta description length, title pixel width or missing alt text on decorative images can wait until tiers 1 to 3 are clean. They are worth fixing eventually, but they rarely explain a traffic problem.

Fixing technical SEO issues in the right order

Technical SEO issues get fixed fastest when someone decides what matters, in what order, and who owns each fix. Run the three data sources, group by template, fix tier 1 the same day, schedule tier 2 for the next sprint, and plan tier 3 into normal development. Then add the checks that caught each problem to your release process, because most technical regressions ship with a deploy.

If your audit report is a thousand-line spreadsheet and you need it turned into a short, ordered list with owners, that is exactly what our AI visibility audit delivers: the blocking issues first, the signal problems next, and the AI-crawler access checks that standard crawlers don’t run.