Search Console listed 1,900 URLs as crawled - currently not indexed. Titles on the money pages still described last year’s offer. The new cluster had no internal links from anywhere that already ranks.

That is three failures on one site, and they are not the same job. A founder buying SEO in the Philippines gets sold a retainer labelled “SEO” and then watches crawl waste, weak titles and thin intent all sit in the same monthly report. We split the work because the next useful action is different in each layer.

Technical SEO vs on-page SEO vs content SEO is a buying decision, not a vocabulary test. If the crawler cannot fetch and keep the URL, titles will not save it. If the URL is in the index and the title still misses the query, more articles will not save it. If titles already match and the cluster still has no coverage for the jobs people search, another robots.txt pass will not save it.

What the crawl actually proves

A crawl is evidence of access. It is not evidence of ranking, and it is not evidence that the copy is right.

When we run a crawl we care about status codes, canonicals, robots, noindex, redirect chains, parameter copies, hreflang, sitemap membership and whether JavaScript is hiding the main content from Googlebot. Those findings tell us whether Google can request the URL, understand which version is canonical, and keep it.

They do not tell us whether the title describes the offer you sell now. They do not tell us whether the page answers the intent behind the query. They do not tell us whether a money page has a single internal link from a blog post that itself is orphaned.

If 1,900 URLs are crawled and not indexed, the next useful thing is not a content calendar. The next useful thing is why Google fetched them and then declined to keep them. Duplicate canonicals, thin parameter URLs, a sitemap stuffed with 301s, a render that never finishes - those are technical. We will not brief writers against that list.

Technical SEO is access and indexation

Technical SEO is the work that makes URLs fetchable, unique and eligible for the index. On a Philippines site that usually means hosting and TTFB, HTTPS, XML sitemaps, robots.txt, canonical tags, pagination, faceted filters on ecommerce, mobile rendering, Core Web Vitals, and hreflang when you serve PH and another market from the same property.

A sitemap does not force indexation. It is a hint. The Google sitemaps overview still says submit only canonical, indexable URLs - if we dump every parameter and 301 into that file, we teach the crawler the wrong map of the site.

Technical work also covers migrations. A DNS cut, a HTTP to HTTPS move, a www to apex change, or a CMS rebuild will leak equity if 301s, canonicals and sitemaps are wrong for even a week. That is still technical SEO vs on-page SEO: the titles can be perfect on URLs that no longer exist.

We treat log files and Search Console coverage as the source of truth, not a Lighthouse screenshot from one laptop. Crawl budget on a 4,000-URL catalogue is a real constraint. Crawl budget on a 40-URL brochure site is usually an excuse to avoid looking at titles and intent.

If the site cannot be crawled cleanly, we stop there. On-page and content wait.

On-page SEO is the URL Google already found

On-page SEO starts after the URL returns 200, is canonical, and is allowed in the index. Then we work the document Google already has: title, meta description, H1, heading order, first paragraph, image filenames and alt, structured data, and the internal links that sit on that URL.

This is where technical seo vs on page seo actually splits on a live job. Changing a title is on-page. Changing the canonical that made two titles compete is technical. Adding an FAQ schema block is on-page. Fixing the template that output the same FAQ on 800 tag pages is technical.

We see founders buy “on-page” and receive a spreadsheet of title rewrites for URLs that are noindex, canonicalised elsewhere, or blocked in robots. That spreadsheet is not on-page work. It is a list of pages the crawler is not supposed to use.

Once those URLs return 200 and stay in the index, titles, headings and on-page internal links are the next useful job - that is the work in our on page seo services philippines scope, not a second technical retainer.

On-page also includes the bits of the template that every URL inherits: breadcrumb markup, organisation schema, pagination rel, and whether the primary CTA is in the HTML or only in a delayed widget. If the crawler never sees the CTA, that is still an on-page failure sitting on a technical cause.

Content SEO is intent and missing coverage

Content SEO is the decision about which URLs should exist, what job each URL does, and whether the current set answers the queries you want. Intent, cannibalisation, cluster design, and the brief for a new URL live here.

Content seo vs technical seo is the comparison founders get wrong after a clean crawl. The site is indexable. Search Console looks tidy. Publishing continues. Rankings do not move because three articles all target the same head term, none of them cover the comparison query, and the service page is 400 words of company history.

We do not treat “more blog posts” as content SEO. A weekly post with no internal links, no distinct intent, and no path to a money page is inventory, not a cluster. Content SEO is the map: this URL owns this intent, this URL supports it, this URL should be merged, this URL should not be written.

If the crawl is clean and titles already match the query, the gap is coverage and intent - that sits in our content seo services philippines work, which starts from the queries the current URLs cannot answer.

British-led copy on a Philippines site still has to respect local intent. “SEO agency Manila” and “technical SEO audit” are different jobs. Mixing UK phrasing into a PH commercial query is a content failure, not a crawl failure. We brief against the SERP in front of us, not against a keyword list exported in 2022.

Technical seo vs on page seo when both quotes look similar

Two proposals can use the same nouns and mean opposite work. Ask what changes in the HTML, what changes in Search Console, and what does not get touched.

If the deliverable is robots, sitemaps, canonicals, redirects, rendering, hreflang, and coverage reports, that is technical. If the deliverable is titles, H1s, meta, on-page copy edits, schema on existing URLs, and internal links between current templates, that is on-page.

A useful test: would this task still be needed if we never published another article? Redirect mapping, yes. A new 2,000-word guide, no. Title rewrites on the five service URLs, yes. A pillar-and-cluster plan for next quarter, no.

Another test: would this task still be needed if we froze the CMS templates? Then it is probably content or a one-off on-page pass, not a technical programme.

We refuse to bundle them into one unnamed line item because the founder then cannot tell which layer moved. When indexation recovers and titles stay wrong, you need on-page, not another crawl. When titles are sharp and the URL is still excluded, you need technical, not another rewrite.

Content seo vs technical seo after the site crawls clean

Content seo vs technical seo becomes the live argument once coverage is green. Founders feel they have “done SEO” because the sitemap is submitted and Core Web Vitals passed. The SERP still belongs to pages that answer the query in a way ours do not.

Technical cannot invent a URL that should exist. It can only make the ones you have eligible. If nobody has written the comparison, the pricing explainer, the implementation guide, or the local variant, Google has nothing to rank for those intents. That is content.

The reverse is also true. We will not commission a cluster onto a template that outputs noindex, or onto a pagination scheme that creates infinite crawl paths. Content volume on a broken IA makes the crawl worse. That is why we sequence: access first, then the document, then new URLs.

Cannibalisation looks like a content problem and often has a technical fingerprint. Two URLs with near-identical titles, a trailing-slash duplicate, and a parameter version in the sitemap will split clicks. Merging the copy without fixing canonicals and sitemap membership leaves the duplicate live. We treat that as a paired job, not a blog rewrite.

Internal links are the noun that appears in all three layers, which is why they get abused in proposals.

A link in the HTML that the crawler cannot reach because of a robots rule is a technical failure. A link that exists but uses “click here” on a money page is an on-page failure. A link that should exist between two intents, and does not, because the cluster was never designed, is a content failure.

We map internal links from the money pages outward and from the supporting URLs back in. Orphan articles do not help a service URL. A footer dump of 80 links does not tell Google which of those 80 matters. The useful internal link is in the body, with anchor text that names the destination, on a URL that already earns crawl attention.

When we audit, we count inlinks to the commercial URLs, not total links in the crawl. A blog with 200 posts and four inlinks to the primary service page is a content architecture problem sitting on top of a site that may already be technically fine.

The order we run on a live site

We do not start three workstreams on day one. The order is the decision.

First, crawl and coverage. Fix blocked resources, broken redirects, duplicate canonicals, junk in the sitemap, and anything that keeps money URLs out of the index. If a migration is in flight, that work jumps the queue. Local listings and Google Business Profile do not replace this; they sit beside it.

Second, on-page on the URLs that survived. Titles, H1s, intent match in the opening copy, schema that matches the document, and internal links that already have a destination. We do this on the templates and the five to twenty URLs that carry the business, not on every tag archive.

Third, content. Only then do we decide which new URLs to create, which to merge, and which to leave alone. Intent research here is against the live SERP, including AI Overviews where they appear, not against a volume column in a spreadsheet.

AI search work does not replace the three layers. If the document is uncrawlable, it will not be a source. If the title and entity markup are vague, it will not be cited cleanly. If the content does not answer the question, there is nothing to cite. We treat AI search as a reason to be stricter about crawl, titles and intent, not as a fourth retainer with a new name.

White-label delivery follows the same order. The agency still has to buy the layer that is failing. Relabelling technical work as content does not change the crawl.

What to send before we scope an audit

Send Search Console access, the current XML sitemap, a crawl if you have one, the CMS and who can change templates, and the last brief you paid for. If a developer owns robots and redirects, name them. If a writer owns the blog, name them. Split ownership is usually why technical, on-page and content have been sold as one blur.

Tell us which URLs pay the bills. We will not treat a 3,000-URL blog as equal to five service pages. Tell us if a migration, a domain change, or a redesign is coming. Technical SEO vs on-page SEO vs content SEO changes the week a new template ships.

We scope an audit against those facts. The output is which layer is failing, what we would do next, and what we would not touch yet. If the fit is real, that audit becomes the statement of work. If the crawl is already clean and the gap is titles, we will say so. If titles are fine and the gap is intent, we will say that instead.

Buy the layer that is failing. Do not buy three labels for the same month of titles.

Tags:

SEO