Technical SEO – Moz

The 3 Pillars of Technical SEO

If you want the cleanest way to think about technical SEO, forget the 87-point checklists for a second and focus
on three outcomes:

• Crawlability: Search engines can discover your URLs efficiently.
• Indexability: The right URLs are allowed to be indexed, and the wrong ones aren’t.
• User experience signals: The site is fast, stable, mobile-friendly, and secure.

In other words: can Google and Bing find your pages, add them to the library, and recommend
them without apologizing to users afterward?

Crawlability: Roll Out the Red Carpet for Crawlers

Crawlability is about making it easy for search engines to access and navigate your site. If your internal links
are messy, your server is cranky, or your URL patterns spawn infinite duplicates, crawlers will spend their time
wandering… and your important pages may not get visited often enough.

1) Site architecture that doesn’t require a map (because… you’re making the map)

A healthy site structure is predictable and “shallow” enough that important pages aren’t buried 9 clicks deep.
Aim for clear category paths, logical internal linking, and navigation that doesn’t rely on a thousand filters
to reveal core products or content.

Practical example: if you run an eCommerce site, your ideal crawl path might look like:

Home → Category → Subcategory → Product

Not:

Home → Category → Filter → Filter → Filter → “Oops that’s a parameter URL” → Product

2) XML sitemaps: the “here’s everything important” handshake

Sitemaps don’t replace internal links, but they do help search engines discover canonical URLsespecially on large
sites, newly launched sections, or pages that aren’t heavily linked yet. Keep them clean:

• Include only indexable, canonical URLs (don’t invite bots to a party you won’t let them enter).
• Use a sitemap index if you have many sitemaps.
• Keep them updated, and monitor errors in Search Console and Bing Webmaster Tools.

Basic sitemap index example:

3) robots.txt: traffic control, not invisibility cloak

A robots.txt file is best for managing crawler access and crawl loadnot for hiding pages. The big gotcha:
a URL can still appear in search results if it’s blocked but linked elsewhere, because the crawler can learn about
the URL without fetching its content.

Simple example that blocks a low-value folder and points to your sitemap:

Developer-friendly note: don’t accidentally block CSS/JS resources that search engines need to render your pages.
Blocking “helpful” resources can make a page look broken to crawlers (and yes, that hurts).

Indexability: Getting the Right Pages Indexed (and Keeping the Wrong Ones Out)

Crawlability is “can a bot reach it?” Indexability is “should this page actually be stored and shown in search?”
You can have a site that’s easy to crawl and still fail at indexability if you’re sending mixed signals.

1) Noindex: use it intentionally (and don’t pair it with robots.txt by accident)

If you want a page out of search results, the most reliable approach is a noindex directive via
a meta robots tag or an X-Robots-Tag header. But here’s the paradox: search engines generally need to
access the page to see the noindex. So if you block it in robots.txt, the crawler may never see the directive.

Meta robots example:

2) Canonical tags: pick the “main character” URL

Duplicate or near-duplicate pages happen constantly: tracking parameters, print versions, category sorting, HTTP vs HTTPS,
www vs non-www, trailing slashes, and “/index.html” nostalgia. Canonicals tell search engines which version you prefer.

Canonical example:

The key: canonicals are a strong hint, not a magic spell. If your internal links, sitemaps, redirects, and canonical tags
disagree, Google may pick a different canonical anyway. Your job is consistency across all signals.

3) Redirects: be decisive (301/308 for permanent moves)

When URLs change, permanent server-side redirects help search engines and users land on the correct page. For migrations
and major URL changes, map old → new URLs carefully, avoid redirect chains, and monitor after launch.

• 301 / 308: permanent redirect (best for permanent URL changes)
• 302 / 307: temporary redirect (for short-term changes, tests, maintenance)

Bonus: if you’re migrating, do not “YOLO” it. A site move is one of those moments where technical SEO becomes a team sport
involving SEO, dev, analytics, and the person who owns the DNS account.

4) Thin, low-value, and “infinite” URLs: stop indexing the junk drawer

Index bloat is real. If your site generates endless URLs via filters, internal search, calendar pages, or parameter combos,
you can unintentionally create thousands of low-value pages. That can waste crawl resources and dilute the perceived quality
of your domain. Control it using a mix of:

• Canonicalization (preferred URL)
• Noindex (pages you don’t want in search)
• Parameter handling strategies (especially on faceted navigation)
• Internal linking discipline (don’t spam crawlers with junk links)

Renderability & JavaScript SEO: “But It Works on My Laptop” Isn’t a Strategy

Modern sites often rely on JavaScript frameworks. That’s finesearch engines can process a lot of JS these daysbut you
still need to make it easy for them. Google has specific guidance on how it processes JavaScript and best practices to
help JS apps show up reliably in Search.

What can go wrong on JS-heavy sites?

• Important content loads only after user interactions (bots don’t click like humans).
• Links aren’t real links (divs with click handlers are not as crawler-friendly as anchor tags).
• Canonical tags or metadata differ between raw HTML and rendered output.
• Slow rendering or blocked resources prevent full understanding of the page.

Practical fixes that usually pay off

• Server-side rendering (SSR) or pre-rendering for critical content, especially category and product pages.
• Clean, crawlable internal linking using real <a href> links.
• Consistent canonicals and metadata in both the initial HTML and the rendered state.
• Don’t block key JS/CSS needed for rendering.

Technical SEO here is basically making your app speak “crawler” without losing its “human” personality. Think bilingual,
not compromised.

Performance & Core Web Vitals: Speed, But Make It Meaningful

Site performance is both a user experience issue and a search visibility issue. Google’s Core Web Vitals focus on real-user
experience measurementsso it’s not just “my homepage loads fast on office Wi-Fi,” it’s “does it feel fast for actual humans?”

Core Web Vitals targets (the ones people actually use)

• LCP (Largest Contentful Paint): aim for ≤ 2.5s
• INP (Interaction to Next Paint): aim for < 200ms
• CLS (Cumulative Layout Shift): aim for ≤ 0.1

Fixes that tend to move the needle

• Images: compress, use modern formats, define dimensions to prevent layout shifts.
• Critical rendering path: reduce render-blocking CSS/JS, prioritize above-the-fold content.
• Hosting & caching: use caching headers, CDN delivery, and sane cache invalidation.
• Third-party scripts: audit them like you’re paying per kilobyte (because you kind of are).

Also: HTTPS matters. Search engines have treated HTTPS as a ranking signal for years, and it’s table stakes for trust. If your
site still serves mixed content or has sloppy redirects from HTTP to HTTPS, your technical foundation is wobbling.

Structured Data: Give Search Engines Context (Not Just Words)

Structured data (often using JSON-LD schema markup) helps search engines understand what your content is, not just what it
says. Done well, it can unlock richer search features (where eligible). Done badly, it can create errors, warnings, and the kind of
confusion that makes you question your life choices.

Start with the schema types that match your site

• Organizations & local businesses
• Products (with offers, availability, ratings where appropriate)
• Articles (news/blog content)
• FAQs (where policy and usefulness align)
• Breadcrumbs (especially helpful for large sites)

Validate early, validate often

Use Google’s Rich Results Test to confirm which rich result types can be generated from your structured data and to catch markup
issues before they become “mysterious” traffic drops.

Simple JSON-LD example for an Article:

Pro tip: don’t mark up content that isn’t visible to users. If your schema describes five-star reviews you don’t display, you’re basically
asking search engines to trust you with their wallet and their keys. They won’t.

International SEO: hreflang Without the Horror Movie Soundtrack

If you publish localized versions of pages (language and/or region variants), hreflang helps search engines understand that these
pages are related alternativesnot duplicates competing to cannibalize each other.

Three ways hreflang can be implemented

• In the HTML <head>
• In HTTP headers (common for non-HTML content)
• In XML sitemaps

Common hreflang mistakes

• Missing return tags (hreflang annotations should be reciprocal)
• Wrong language/region codes
• Canonicals pointing to a different language version
• Mixing localization strategy (folders vs subdomains vs ccTLDs) without consistent signals

Basic HTML example (simplified):

A Moz-Style Technical SEO Audit Workflow

“Moz-style” doesn’t mean “buy a tool and pray.” It means a repeatable process: discover issues, measure impact, prioritize fixes, validate outcomes.
Here’s a workflow that works whether you’re using Moz Pro, Search Console, Bing’s tools, or a crawler of your choice.

Step 1: Baseline the fundamentals

• Confirm indexation patterns in Google Search Console (coverage/indexing, sitemaps, CWV reports).
• Check Bing visibility and crawl/index feedback in Bing Webmaster Tools.
• Spot-check robots.txt, XML sitemap(s), canonical rules, and redirect behavior.

Step 2: Crawl the site like a search engine would

• Identify broken internal links (wasted link equity and bad UX).
• Find redirect chains, loops, and inconsistent HTTP/HTTPS or www/non-www paths.
• Audit duplicate titles, meta descriptions, and thin template pages that multiply like gremlins.

Step 3: Prioritize with impact vs effort

Fixing one canonicalization rule that affects 50,000 URLs usually beats polishing a meta description on a page that gets 12 clicks a year.
Rank issues by:

• Severity: Does it block crawling/indexing or break rendering?
• Reach: How many URLs are affected?
• Opportunity: Are high-value pages being held back?
• Effort: Can it be fixed safely in a sprint?

Step 4: Validate fixes (don’t just ship and vanish)

• Re-crawl the affected sections.
• Use URL inspection and live tests for key pages.
• Monitor indexing changes, CWV movement, and organic performance trends.

Common Technical SEO Facepalms (and How to Avoid Them)

• Blocking the whole site in robots.txt during a redesign and “forgetting” to undo it. (Classic.)
• Canonical tags pointing everywhere like a confused GPS.
• Redirect chains that turn one click into a relay race.
• Indexing internal search pages and accidentally creating a million thin URLs.
• Shipping JS-only navigation where links aren’t really links.
• Core Web Vitals whiplash caused by un-audited third-party scripts.

Technical SEO isn’t about being perfectit’s about removing friction. Every fix is one less obstacle between your content and the people searching for it.

A Simple 90-Day Technical SEO Roadmap

Days 1–15: Stop the bleeding

• Fix robots.txt accidents, noindex mistakes, and sitemap errors.
• Resolve major 5xx issues, broken templates, and obvious redirect loops.
• Confirm your canonical + HTTPS + preferred host setup (www vs non-www).

Days 16–45: Build crawl and index efficiency

• Clean up duplicate URL patterns, parameter traps, and index bloat.
• Improve internal linking to key pages (categories, money pages, cornerstone content).
• Set up structured data for the page types that matter most.

Days 46–90: Improve experience and future-proof

• Prioritize CWV fixes (LCP/INP/CLS) based on actual user data.
• Address JavaScript rendering risks on critical templates.
• Create ongoing monitoring: scheduled crawls, dashboards, and launch checklists.

Experiences From the Technical SEO Trenches (Composite Stories)

I don’t have personal “war stories,” but I can absolutely share the kinds of scenarios that show up repeatedly in real technical SEO auditsespecially the
ones that feel like they were written by a sitcom writer who loves HTTP status codes.

1) The robots.txt “Oops” that nukes organic traffic. A team launches a new design and blocks / in robots.txt to keep staging
out of the index. Launch day arrives. The site goes live. The block stays. Google can still show some URLs, but crawlers can’t fetch content, so pages slowly
fall out or fail to update. The fix is easy (remove the block), but the recovery takes longer because search engines need time to recrawl and reprocess.
Lesson: make robots.txt part of your launch checklist, and always test it after deployment.

2) The “canonical confetti” situation. An eCommerce platform generates multiple URLs for the same product (filters, tracking parameters, sorting,
alternate paths). Someone adds canonicalsbut they point to a mix of URLs depending on template conditions. Search Console starts reporting “Duplicate, Google chose
different canonical than user.” Rankings fluctuate because signals are inconsistent. Lesson: canonicals must align with internal links and sitemaps. Pick one URL
format and make everything else point to it, like loyal penguins following their leader.

3) The migration that forgets the boring part (redirect mapping). The brand changes URL structure, but only redirects top pages. Thousands of long-tail
pages 404. Users bounce. Link equity leaks. The SEO team gets blamed for “Google being mean.” Lesson: migrations are engineering projects. Build a complete old→new
mapping, use permanent redirects for moved pages, avoid chains, and monitor both Google and Bing data after launch.

4) The JavaScript app that hides the good stuff behind a button. The site loads a shell, then fetches product details only after a user click. Humans
love it. Crawlers see a mostly empty page and a pile of scripts. Indexing is inconsistent; rich results never show. Lesson: render critical content in the initial HTML
(SSR or pre-render) and make links crawlable. You can keep the app-y experiencejust don’t require a bot to behave like a caffeinated shopper.

5) Core Web Vitals sabotage by a “helpful” script. A marketing team adds three chat widgets, two tag managers, and a personalization tool. Suddenly CLS
spikes because banners push content down, and INP worsens because main-thread work balloons. Rankings don’t necessarily collapse overnight, but conversions do. Lesson:
treat third-party scripts like roommates: fine in moderation, but if you move in twelve at once, nobody sleeps.

If you want a “Moz-flavored” takeaway from these scenarios, it’s this: technical SEO is about systems. Once you build clean systemscrawl paths, indexation rules,
performance guardrailsyou stop playing whack-a-mole and start compounding results.