Technical SEO
Why Technical SEO Is the Best Investment for Large Websites
By Rehan Javed · Updated · 6 min read
On a 10-page site, good content and a few links can be enough. On a site with thousands of URLs, the limit is usually what Google can crawl, render and understand. One client account I work on has 2.76M impressions in Search Console. At that scale, small technical issues cost real traffic.
1. Crawl budget
Google won't crawl every URL every day. Filters, parameters and duplicate paths waste the visits you get.
Fix: canonical rules, parameter handling, robots rules for junk URLs, and log file review to see where Googlebot actually spends its time.
2. JavaScript rendering (Next.js and React)
Client-side rendered pages can look empty to crawlers. Server-side rendering or static generation in Next.js solves most of this, as long as metadata, links and content are in the initial HTML.
3. Core Web Vitals at scale
Fix templates, not individual pages: image sizing, font loading and third-party scripts. One template fix can improve thousands of URLs.
4. Site depth and internal links
Important pages should be within three clicks of the homepage. Hub pages and contextual links send authority to the pages that bring in revenue.
5. Schema generated from your data
Product, Article, LocalBusiness and FAQ schema, generated automatically from your CMS so it stays accurate.
6. Migrations: the most expensive mistake
Changing URLs without 301 redirects is the fastest way to lose rankings you built over years. Map every old URL to its new one before launch. If pages have already dropped, you can check whether an old URL redirects and whether the new one can be indexed.
What a migration taught me
I learned point 6 the hard way on my own site. I moved it to Next.js in September 2026 and changed the inner URLs. The new site was technically clean: fast, server-rendered, with a valid sitemap. But Google had built trust in the old URLs, and they now returned 404s. Most of the site dropped out of the index while the homepage, whose URL hadn't changed, stayed in.
On a ten-page site that's painful. On a site with ten thousand URLs it can wipe out a year of organic revenue. That's why, for any large site, I build the redirect map before the new site launches: a spreadsheet of every URL that has impressions or links, and its new home. I wrote up how this site lost its inner pages and what I changed separately.
Tools I actually use
- Google Search Console for indexing reasons, crawl stats and page-level performance.
- Screaming Frog or Sitebulb to crawl the site the way a search engine would.
- Server logs, where available, to see which URLs Googlebot really visits.
- Lighthouse and PageSpeed Insights for Core Web Vitals on real templates.
For a quick look at one template before a full crawl, my free SEO audit tool checks a single URL for indexing, canonical, headings, links and schema in a few seconds.
What to fix first
- Indexing blockers and broken redirects
- Rendering issues
- Crawl waste
- Templates and Core Web Vitals
- Internal links and schema
Keep reading
FAQ
At what size does technical SEO become critical?
Once a site has hundreds of URLs, or generates URLs automatically through filters, search or tags, crawl and indexing problems start to cost real traffic.
Is Next.js good for SEO?
Yes, when pages are server-rendered or statically generated, so the content, links and metadata are in the initial HTML. Client-only rendering is where problems start.
What should happen before a site migration?
A full URL inventory, a redirect map from every old URL to its new equivalent, a staging crawl, and a plan to monitor Search Console for 8–12 weeks after launch.