30 Technical SEO Issues: What To Fix And What You Can Safely Ignore

Technical SEO issues are defects in how your site is built and served that stop search engines from reaching, reading, or trusting your pages. They sit underneath your content rather than inside it, which is why a page with excellent writing can still fail to rank, and why a site can lose traffic without anyone touching a word of copy.

These defects matter more now than they did five years ago because more systems read your site. Google crawls a page, renders it on a queue, then indexes it. AI crawlers work differently, fetching raw HTML and moving on. A page that Google forgives can be genuinely invisible to the systems increasingly answering your buyers' questions, which means the same defect can cost you twice.

This is a long and detailed piece in which our senior technical SEO experts addressed the most common technical SEO issues, ordered by where they break the pipeline rather than by how often they appear. You'll find how to diagnose them, a severity rating for both Google and AI crawlers, an honest estimate of what each fix costs to implement, which ones to work on first, and which ones you can leave alone.

Diagnosis comes before repair, and the order you run your tools in changes what you find. Each one sees a different slice of the problem.

Start with Google Search Console, because it reports what Google did, not what a tool thinks Google might do. The Page Indexing report tells you which URLs are excluded and why, and the Core Web Vitals report tells you how real visits performed.

Run a full site crawl second. Screaming Frog SEO Spider, Sitebulb, and Semrush Site Audit will each map your internal links, status codes, canonicals, and directives in a way Search Console never shows you.

Finish with PageSpeed Insights on the templates that earn money. Running it on your homepage tells you about your homepage, which is rarely the page with a conversion problem.

A crawler sees your site the way a well-behaved bot would, following links from a starting point. It won't find pages nothing links to, and it won't tell you what a non-rendering crawler experiences unless you configure it to.

Search Console sees Google's actual behavior but only for URLs Google knows about, and it reports on a delay. Log files see every request any crawler made, which no other source can tell you, and most teams never look at them.

Audit tools rank by detection, not by consequence. The 2025 Web Almanac's analysis of millions of sites shows what this looks like at scale. Title tags appear on 98.6% of pages, meta descriptions on 67.7%, and the meta robots tag on 46.2%. However, the specific defects that move traffic (like accidental noindex directives, JavaScript-only content, orphan pages) show up on a small fraction of sites. Prevalence and impact run in opposite directions more often than not, and the rare problem is usually the expensive one.

Screaming Frog's own documentation makes this point plainly, noting that flags lack context about your site. A flag is a hypothesis about a problem. It becomes a work order only after you decide the page matters and the fix is worth the hours.

The first table explains the labels used throughout: severity for Google, severity for AI crawlers, and the effort required to fix.

Every issue below carries three labels so you can triage at a glance instead of reading through the fix to figure out what you're dealing with.

Two severity ratings sit alongside that fix-effort label on every issue. One for Google, one for AI crawlers, because the same defect often costs different amounts on each. Treat all three as our assessment based on how these defects behave on client sites, not a vendor's scoring system.

Now the master summary table pulling all thirty issues into one scannable reference:

Thirty issues is a lot to read cold, so here's the full list at a glance before you dive into the details on each one.

If you're weighing severity against effort the way the guide recommends later, the Severe-and-Config rows at the top are where an afternoon buys you the most.

Nothing downstream matters while these are unresolved. A page a crawler can't reach cannot be rendered, indexed, ranked, or cited, so this stage is always where you start.

Google: Severe | AI crawlers: Severe | Fix: Config

A single disallow line can hide an entire site section from every crawler at once. It is the cheapest mistake to make and among the cheapest to fix.

Looks like: A /blog/ or /products/ path sitting behind a disallow rule that someone added during a migration and nobody removed.

Fix:

Google: Severe | AI crawlers: Severe | Fix: Config

Staging environments carry a site-wide noindex to keep them out of search results. When a deploy pushes that tag to production, pages start dropping out of the index within days, and the cause is invisible in the rendered page.

Looks like: Traffic falling off a cliff about a week after a release, with Search Console showing pages moving to "Excluded by 'noindex' tag."

Fix:

You can read more about the indexing problems that keep pages out of Google in our dedicated guide.

Google: Medium | AI crawlers: Medium | Fix: Config

A missing robots.txt is read as permission to crawl everything, which is usually harmless. A 5xx response is a different matter, because crawlers may slow or pause crawling rather than risk ignoring rules they couldn't read.

Looks like: A file generated dynamically that returns a 503 during traffic spikes.

Fix:

Many CDNs and security plugins block AI crawlers by default, and most site owners don't realize it until someone runs a log check. Per Cloudflare Radar's Q2 2026 AI Insights data, the AI crawler landscape went genuinely multipolar in 2026: Googlebot's share of AI-bot traffic fell to 27.5%, less than half its 57.2% share a year earlier, while ClaudeBot rose to 13.9%, Meta-ExternalAgent reached 12.7%, and GPTBot sat at 10.2%. That's four crawlers each accounting for a meaningful slice of the traffic feeding AI answers, none of them dominant. Blocking any one of them removes you from a share of the answers being generated in your category, and blocking several removes you from most of them.

The rate of change also matters. Anthropic's ClaudeBot went from outside the named top nine in July 2025 to the second-largest AI crawler by July 2026, per Cloudflare's continuous monitoring. Any block list that hasn't been reviewed in the last two quarters is probably enforcing decisions no one at the company would make today if asked directly.

Looks like: A bot-protection rule blocking GPTBot, ClaudeBot, and PerplexityBot that nobody in marketing knows exists, usually inherited from a CDN default nobody remembers configuring.

Fix:

Google: Medium | AI crawlers: High | Fix: Content

Each hop in a chain costs a crawl request and adds a place for the path to break. A 302 left in place for three years tells crawlers the original URL is still the real one, which is rarely what anyone intended.

Looks like: An old campaign URL redirecting to a category, which redirects to a renamed category, which redirects to the HTTPS version.

Fix:

Google: High | AI crawlers: High | Fix: Engineering

Server errors reduce how much a crawler is willing to request from you. Slow response time does the same thing more quietly, because a crawler waiting longer per request fetches fewer pages in the same window.

Looks like: Time to first byte climbing during business hours while Search Console shows crawl rate falling in the same period.

Fix:

Google: Medium | AI crawlers: Medium | Fix: Content

Crawl depth works as a rough signal of how important you consider a page. Pages sitting five or six clicks from the homepage get crawled less often and refreshed more slowly, which delays every change you make to them.

Looks like: A high-margin product reachable only through four levels of category navigation.

Fix:

This is the stage where Google and AI crawlers diverge most sharply, and where a page can pass every other check while still being empty to half the systems reading it.

Google: High | AI crawlers: Severe | Fix: Engineering

Google crawls, queues the page for rendering, then indexes what the render produced, so client-rendered content usually gets indexed eventually. AI crawlers don't wait. Research into AI crawler behavior found that ChatGPT's crawler fetched JavaScript files on 11.50% of requests and Claude's on 23.84%, and neither executed any of it. Gemini and AppleBot are exceptions that do render, which makes the behavior inconsistent across the systems your buyers use.

Looks like: View source showing an empty container where your product copy should be.

Fix:

Our guide to how Google and AI crawlers handle JavaScript rendering covers the trade-offs between rendering approaches in more depth.

Google: Medium | AI crawlers: High | Fix: Engineering

Schema added by a tag manager or a client-side script arrives after the raw HTML does. A very small number of pages add structured data only through JavaScript, and others modify it after render, so any system reading raw HTML sees nothing at all.

Looks like: Rich results appearing in Google while the markup stays invisible to every other reader of the page.

Fix:

Google: Medium | AI crawlers: High | Fix: Engineering

Lazy loading tied to scroll events assumes a reader who scrolls. Crawlers don't scroll, so content set to load partway down the page can go unread entirely.

Looks like: A long article that loads its second half only once the reader passes the midpoint.

Fix:

Google: High | AI crawlers: Medium | Fix: Engineering

Mobile-first indexing means the mobile version of your page is the version Google indexes. Content hidden on mobile, or structured data present only on desktop, is content Google doesn't count.

Looks like: A comparison table that renders on desktop and collapses to nothing on a phone.

Fix:

Google: Medium | AI crawlers: Low | Fix: Engineering

Stylesheets and scripts loaded in the head stop the browser from painting anything. This surfaces as a slow Largest Contentful Paint, which is the weakest of the three Core Web Vitals on mobile.

Looks like: Three font files and a chat widget loading ahead of the hero image.

Fix:

A crawled, rendered page still has to earn a place in the index. Most of the defects at this stage come from sending contradictory instructions rather than from sending none.

Google: High | AI crawlers: Medium | Fix: Config

The same page reachable at several addresses splits its signals across all of them. Duplicate content shows up in a small minority of audited sites, which makes it a rare problem rather than a routine one, and rare problems tend to be the costly ones.

Looks like: One product available at four URLs through a trailing slash, an uppercase character, a tracking parameter, and an unredirected HTTP version.

Fix:

Google: High | AI crawlers: Medium | Fix: Config

Canonical tags are hints, and Google discards hints that don't make sense. Pages that canonicalize to each other, or to a redirected URL, or to a page that no longer exists, leave Google to work it out alone.

Looks like: Page A pointing its canonical at page B while page B points back at page A.

Fix:

Google: High | AI crawlers: Medium | Fix: Config

A canonical says to index a different page instead. A noindex says not to index this page. Sent together, they contradict each other, and Google may end up applying the noindex to the page you wanted indexed.

Looks like: A filtered category page carrying both a noindex directive and a canonical pointing at the main category.

Fix:

Google: Medium | AI crawlers: Low | Fix: Config

Your sitemap states which URLs you consider canonical and worth indexing. Filling it with redirects, 404s, noindexed pages, and parameter variants weakens that statement everywhere it applies.

Looks like: A sitemap generated straight from the database, listing every URL the site has ever created.

Fix:

Google: Medium | AI crawlers: Medium | Fix: Engineering

A page saying "product not found" while returning a 200 status tells crawlers everything is fine. Google usually detects these and reclassifies them, and once it does, it trusts your status codes less across the whole site.

Looks like: Discontinued products serving an empty template with a successful status code.

Fix:

Google: Medium | AI crawlers: Low | Fix: Engineering

Filters that combine freely can create more URLs than the site has products. Google's guidance puts crawl-budget concerns at roughly ten thousand URLs and above, which is precisely where large ecommerce catalogs sit.

Looks like: Color, size, price, and brand filters combining into hundreds of thousands of crawlable addresses.

Fix:

These defects won't keep a page out of search results, but they cap how well it performs once it's there. Most of them are also the ones your audit tool flags loudest.

Google: Medium | AI crawlers: Low | Fix: Engineering

Lab scores measure a simulated load on a simulated connection. Field data measures real visits, and only 48% of mobile origins and 56% of desktop origins pass all three Core Web Vitals. Largest Contentful Paint is the weakest on mobile, passing on 62% of origins versus 77% for Interaction to Next Paint and 81% for Cumulative Layout Shift.

Looks like: A near-perfect lab score sitting alongside a failing field assessment for the same URL.

Fix:

Speed has a commercial cost beyond the thresholds. Shopify's January-February 2026 analysis of actively-selling stores found that every 100 milliseconds of extra load time costs about 3.5% of conversion, and every 32 milliseconds of interaction delay costs about 1.5%. Stores at a 2.5-second Largest Contentful Paint (exactly Google's 'good' threshold) converted roughly 30% below stores at 1.5 seconds. Passing Core Web Vitals isn't the finish line; it's the entry bar.

Google: High | AI crawlers: High | Fix: Content

A page that nothing links to is reachable only through your sitemap. Crawlers find it rarely and treat it as unimportant, which is a fair reading, because nothing on your own site suggests otherwise.

Looks like: Campaign landing pages that were built, published, and never linked from anywhere.

Fix:

Google: Medium | AI crawlers: Medium | Fix: Content

Internal links pointing at 404s waste crawl requests and strand readers mid-journey. They accumulate quietly after every migration, redesign, and product retirement, so they're worth rechecking rather than fixing once.

Looks like: Older blog posts linking to product pages retired two years ago.

Fix:

Google: High | AI crawlers: High | Fix: Content

Navigation links appear on every page and say almost nothing about how your topics relate. Links in body content build an internal-link graph and topical authority that a search engine can interpret.

Looks like: A site where every internal link lives in the header, the footer, or an automated related-posts widget.

Fix:

Google: Medium | AI crawlers: Low | Fix: Content

Title tags appear on 98.6% of desktop pages while meta descriptions appear on only 67.7%, so the gap is usually in descriptions. Duplication across a template is more common than absence and equally unhelpful.

Looks like: Forty category pages sharing one title made up of the site name and a suffix.

Fix:

Google: Medium | AI crawlers: Medium | Fix: Content

Pages carrying almost no content spread your site's signals across URLs that satisfy nobody. This costs more on a small site, where a handful of thin pages can be a large share of everything you have.

Looks like: Tag archives, empty author pages, and location pages differing only by the city name.

Fix:

Google: Medium | AI crawlers: Low | Fix: Config

A secure page loading an insecure resource is a mixed-content page. Browsers block or warn on these, and the security signal you paid for stops applying cleanly.

Looks like: An HTTPS page pulling images over HTTP from an old CDN path.

Fix:

Google: Medium | AI crawlers: Low | Fix: Content

Popups that cover the main content immediately on arrival are treated as a poor mobile experience. Cookie notices and age gates required by law are exceptions. A newsletter modal is not.

Looks like: A discount overlay covering the page two seconds after a visitor lands on it.

Fix:

This stage has no equivalent in most technical SEO checklists, so it's worth working through separately. These defects rarely affect your Google rankings and can quietly remove you from the answers being generated around your category.

Google: Low | AI crawlers: Severe | Fix: Engineering

This is the same defect as issue 8 viewed from the other side. A page Google renders, indexes, and ranks perfectly well can be permanently empty to systems that read raw HTML and never execute anything.

Looks like: A page ranking on the first result page in Google that never appears as a citation anywhere else.

Fix:

Google: Medium | AI crawlers: High | Fix: Content

Extraction systems lift passages rather than whole pages. An answer sitting in the middle of a long undifferentiated section is harder to quote than the same answer placed directly beneath a heading that matches the question.

Looks like: Pricing explained in the ninth paragraph of a page carrying three headings.

Fix:

Google: Medium | AI crawlers: High | Fix: Engineering

Structured data adoption is lower than most people assume. WebSite markup appears on 12.73% of mobile pages, Organization on 7.16%, and LocalBusiness on 3.97%, which leaves most sites describing themselves in prose alone and hoping it's understood.

Looks like: A company with no Organization markup, no sameAs references, and no machine-readable connection between the brand and its own profiles.

Fix:

Google: Low | AI crawlers: High | Fix: Config

Most sites have never decided whether to allow AI crawlers. The decision gets made by a CDN default or a plugin setting, which means allowing everything is also a decision, just not one anybody made on purpose.

Looks like: A robots.txt that has never mentioned GPTBot, ClaudeBot, or PerplexityBot, sitting behind a firewall rule quietly blocking two of them.

Fix:

Thirty issues is more than any team fixes in a quarter, so the sequencing question matters more than the list itself. Two things decide the order.

The first is severity divided by effort rather than severity alone. A Severe issue with a Config fix is an afternoon's work with a large payoff, which is why the robots.txt and noindex items sit at the top of this article. A Medium issue needing sprint work from an engineering team is a different proposition, and it belongs in a roadmap rather than in this week's tasks.

The second is stage order, which breaks ties the first rule can't. A defect at the crawl stage makes every fix downstream of it pointless, because a page nothing can reach won't benefit from faster loading or better markup. Work the stages in the order they appear here, and inside each stage sort by effort.

Two habits make this easier to hold to:

Audit reports are generated by tools that can't see your commercial situation, and a fair number of the flags they raise aren't worth the hours. Knowing which to ignore is the more valuable half of this skill.

Leave these alone in most cases:

The rule underneath all six is straightforward enough to apply on the spot. Only fix what you can name the page and the money for. When you can't say which URL improves and what that improvement is worth, you're working through a list rather than doing SEO.

Most technical defects arrive through a deploy, a plugin update, or a platform migration, so they show up between audits rather than during them. Monitoring is about catching regressions in days rather than discovering them next quarter.

A workable cadence looks like this:

The distinction worth holding onto is between auditing and monitoring. An audit asks what's wrong with the site. Monitoring asks what changed since last week, which is a narrower question and a far faster one to answer.

Timelines vary by defect type more than by site size, and the honest answer is that some fixes show up in days while others take a quarter.

Indexability fixes are the fastest. Removing a stray noindex or unblocking a path in robots.txt can restore pages within days of the next crawl, and you can speed that up by requesting indexing on the highest-value URLs.

Canonical and duplication fixes take longer, because Google has to recrawl every affected variant before it can consolidate them. Expect a few weeks on a mid-sized site.

Core Web Vitals move a lot slower, and predictably so. Field data is reported over a rolling 28-day window, which means a fix deployed today cannot show a full effect for four weeks no matter how much the lab score improved on the day.

Internal linking and authority changes are the slowest and the hardest to attribute, since they compound with everything else you publish.

Most of the list above won't matter to your site this quarter. Thirty defects exist, your audit will flag a hundred and forty things, and the work that moves revenue usually comes down to five or six of them on the pages that already earn. The skill isn't knowing what every flag means. It's being able to look at a report and say which handful deserves engineering time, then defending that decision when the report says everything is urgent.

What has changed is the cost of getting that judgment wrong at the top of the pipeline. A page Google forgives can be genuinely blank to the systems now answering questions on your buyers' behalf, and that gap is widening rather than closing. Fix the crawl and render stages first, monitor for regressions instead of re-auditing from scratch, and leave the cosmetic flags alone until someone can name the page and the money. Technical SEO issues reward that kind of restraint more than they reward thoroughness.

If you'd rather have someone else make those calls, our team of senior technical SEO experts runs this process as part of our technical SEO services.

For most sites, a full audit twice a year is enough, supported by monthly crawls and weekly Search Console checks. Sites that deploy frequently or run large catalogs benefit from quarterly audits, because each release is an opportunity for a new defect. The audit finds what's wrong; the monitoring cadence catches what broke recently.

Almost never. Manual actions are issued for guideline violations such as unnatural links, cloaking, or spam, not for slow pages or broken canonicals. Technical defects hurt through lost crawling, indexing, and ranking rather than through punishment, which matters because the recovery path is different. You fix the defect and wait for a recrawl rather than filing a reconsideration request.

Not for all of them. Roughly a third of the issues in this guide are configuration changes you can make in an admin panel, a robots.txt file, or a CMS setting without touching code. Rendering problems, server response times, and structured data output usually do need engineering time, which is why estimating fix effort before you prioritize saves so much negotiation later.

It matters more, not less. AI crawlers fetch raw HTML and mostly don't execute JavaScript, so a page that Google renders and ranks can be empty to the systems generating answers. That makes rendering, markup, and crawler access decisions more consequential now than they were when Google was the only system reading your site.

Indexability first, which means robots.txt, noindex tags, and making sure your important pages are internally linked. Small sites rarely have crawl budget problems, and they rarely benefit from faceted navigation work or hreflang. Get every page you care about crawlable, rendered in raw HTML, and linked from somewhere relevant, and you've handled most of what will ever matter at that scale.