On Page SEO vs Technical SEO

I decide by running a single crawl first. If I find that over 30% of pages return 4xx errors, are blocked by robots.txt, or have noindex tags without a clear strategy, I stop everything and fix those technical issues. A well-written page that Google cannot access is wasted effort. I learned this the hard way with a client site in the travel niche. The content was strong — detailed destination guides with original photography — but organic traffic hovered around 2,000 clicks a month. A crawl revealed that parameter-based URLs were creating thousands of duplicate pages, wasting the crawl budget and causing half the real pages to be deindexed. I spent two weeks cleaning up canonical tags, setting consistent URL structures, and removing blocking directives from the sitemap. Once index coverage stabilised at 95%, I shifted to on-page work: rewriting title tags to match long-tail queries and improving heading hierarchy. Within three months, clicks rose to 4,000 a month. The decision rule I now live by: technical first if the site has crawl or index problems; on-page first if the site is already healthy and you need to improve relevance and click-through. There is an edge case: ecommerce sites with thousands of product pages. Here you often address duplicate content (a technical problem) and product descriptions (an on-page problem) at the same time, because [internal linking](/internal-links-seo/) and canonical tags affect both. I never silo the two. If the technical foundation is solid, I prioritise [on-page SEO](/on-page-seo/) because that directly influences the searcher's decision to click. If the site is not even in the index, no amount of keyword research will help.

The biggest mistake I see is treating technical SEO and on-page SEO as separate projects managed by different people who do not talk to each other. A classic example: someone spends a week producing a perfect [SEO article](/seo-article/) with researched keywords and headings, only to discover the page is blocked by a misplaced robots.txt rule. That week was wasted. Another common pitfall is skipping the foundation. I once watched a team rewrite every [meta description](/meta-description/) on a 500-page site before fixing a broken hreflang setup. Google could not even serve the right language version, so the new meta descriptions were irrelevant for most users. The result was zero traffic improvement. I also see people mislabelling issues. For instance, they treat slow page speed as an on-page concern and try to compress images as a quick fix, when the real problem is server response time or render-blocking JavaScript — both technical. [Image SEO](/image-seo/) does overlap, but you need to know which layer is broken. A third pitfall is thinking that because you have good content, you can skip technical checks. I have seen beautifully written [blogs](/blogs/) that never rank because Google cannot render the JavaScript that loads the text. The content is there, but the technical implementation hides it. My rule is simple: if you cannot answer 'Is every important page indexable?' without running a crawl, you are not ready for on-page work. And if you are, never optimise a title tag in isolation — check the [SEO title](/seo-title/) length and ensure it matches the page's canonical URL. Coordination saves rework.

For the first two years of my SEO career, I believed on-page SEO was more important than technical SEO because it was what users saw. I thought 'if the content is good enough, Google will find it'. That was naive. I spent months polishing SEO copywriting for a client's core service pages. The writing was tight, the headings were aligned with keyword clusters, and the internal links were thoughtful. Yet after six months, none of those pages ranked on the first page. I finally ran a comprehensive technical audit and discovered that the entire section was buried three clicks deep from the homepage with no internal link structure. Google had crawled some pages but assigned them low priority. The page content was fine, but the site architecture was broken. I also used to think that technical SEO was a one-time setup — install an SSL certificate, create a sitemap, and you are done. That is wrong. Technical SEO needs ongoing monitoring: crawl errors pop up after site migrations, new plugins can block resources, and alt text added by a CMS update can break if the system is misconfigured. I now check Google Search Console for index coverage every week. Another thing I got wrong was assuming that mobile friendliness was purely technical. Google uses mobile-first indexing, so if your mobile content differs from desktop, even perfect onpage SEO will not help because Google sees only the mobile version. I used to optimise for desktop and then shrink the page. Now I build mobile-first and test with the Mobile-Friendly Test before writing any content.