What is semantic analysis for SEO?

Semantic analysis for SEO is a way of grouping pages by what they say, not by folder, URL path, or target keyword. Each page gets turned into an embedding. Those embeddings get compared. Pages that point in a similar direction get clustered together.

That cluster view is the "semantic layer" people keep asking for. It is not a new ranking factor. It is a second map of the same crawl: one that follows meaning instead of information architecture.

What semantic analysis is

Start with a crawl. You already have URLs, status codes, titles, and the extracted text. Semantic analysis adds one more step: represent that text as a vector, then measure how close those vectors sit.

The comparison is usually cosine similarity. Pages the model treats as similar land near each other. Pages it treats as different land farther apart. Group the nearby ones and you get clusters: "these pages are talking about roughly the same thing."

That is the whole mechanism. Crawl the site. Embed the pages. Compare them. Cluster the close ones.

A sitemap can tell you a site has /solutions, /blog, and /docs. A keyword export can tell you which terms each section is targeting. Neither tells you whether three blog posts and a solution page are saying the same thing in different language, or whether the docs are carrying the explanation the commercial pages never quite make.

Semantic analysis is the attempt to see that.

In plain terms

If a crawl table is a list of rooms, semantic analysis is sorting those rooms by what happens in them, not by the hallway they sit on.

Two pages can live in different folders and still be about the same job. Two pages can share a folder and still be about different jobs. The model does not know the folder names. It only sees the words on the page, turned into a direction.

The output is a grouping: these pages belong together, those ones don't, and this leftover page is sitting by itself. Whether that grouping is useful still depends on the model, the extraction, and an SEO reading the pages.

A guide and a product page can land next to each other even if the folders disagree. A legal page often sits off by itself. That grouping is the map. It is not a verdict.

Why semantic analysis showed up in SEO

SEOs already had maps. The sitemap and the folder tree show how a site is organized. The keyword map shows what the team meant to target. Both are useful. Both miss a common failure: pages that overlap in meaning without sharing a slug or a primary keyword.

That failure got more expensive when retrieval entered the job. Answer engines do not browse a site the way a person follows nav. They embed a question, embed passages, and pull the ones pointing in the closest direction. If two pages occupy the same neighborhood, both can show up. If the clearest explanation lives far from the commercial page, the commercial page may not be the one that gets used.

So tools started exposing the same grouping retrieval already depends on. Cluster the crawl by meaning. Flag pages that sit too close. Show which topics have a tight group of pages and which have a thin one.

The name varies: semantic map, topic cluster, content graph, embedding view. The idea is the same. Look at the site the way a retrieval system does, then decide whether that picture matches the site the team thinks they built.

Not every map starts from the same text

"Semantic analysis" sounds like one method. In practice, tools feed the model different slices of the page. The comparison math can be identical. The input is not. That choice leaves a fingerprint on the clusters.

• Title tags and meta titles.

  Fast, and already in every crawl export. Also noisy. "Project Management Software | Acme | Free Trial" can repeat, with small swaps, across a whole product section. Brand and template wording pull those pages together even when the body copy is about different jobs.

• An H1 or a short excerpt.

  Cleaner than a templated title, still thin. "Overview" and "Get started" do not give the model much to work with.

• The full rendered page.

  Nav, footer, related-post rails, and cookie copy come along for the ride. Shared chrome becomes shared meaning, so template-heavy sites look more similar than they read.

• Extracted main content, as one blob.

  Closer to what a person would read. A long URL that covers three topics still collapses into one average direction.

• Passages, then a page vector.

  Split the page into chunks, embed each one, then combine those vectors into a page-level embedding. A chunk is a passage cut from the page: a section, a few paragraphs, something closer to what a model retrieves than the whole document.

None of these inputs is automatically wrong. A title-only view can surface naming patterns. A full-page embed makes template similarity obvious, which is sometimes the finding. If two tools disagree about whether two pages are "the same topic," check what they embedded before trusting either cluster.

Titles are a label. Nav is furniture. Body passages are usually the thing being retrieved. The closer the input is to that retrieved text, the closer the map gets to the system you are trying to understand.

How we build the page vector

In Silkra we extract the main content, split it into chunks, embed those chunks, and build the page-level embedding from the average of the chunk vectors. That gives the semantic map one position per URL without treating a long page as a single undifferentiated string.

We keep the chunk vectors too. A query ranks pages by the best-matching passage, not by how close the averaged page vector sits to the question. That is closer to how a language model uses a page: it rarely reads the whole thing as one unit. It pulls sections.

Averaging is still a compromise. A page with one sharp section and three weak ones gets pulled toward the middle. A page that answers two questions can look generic at the page level even when one chunk is a strong match. That is the tradeoff we chose so the map and the retrieval view are built from the same passages. It is not the only honest setup.

What a folder tree misses

We keep running into the same mismatch. The information architecture looks clean. The meaning does not.

On a 105-page software site we measured, randomly paired pages averaged about 0.82 cosine similarity. A privacy policy and a product page could reach 0.85. No SEO would file those under the same topic. The model still saw a lot of shared "this is one website" context: language, brand terms, template residue.

That cut both ways.

• Pages in different sections can be closer than the IA suggests.

  A guide and a product page can occupy the same neighborhood even if one lives in /blog and the other in /platform.

• Pages in the same section can be farther apart than the folder implies.

  An "industries" template that repeats the same three paragraphs will cluster with itself. A page in that folder that actually explains a use case may sit closer to the solutions group.

• High similarity is a prompt to inspect, not a verdict.

  The privacy-policy pair is the reminder. Close in vector space is not the same as "these should be one page."

The useful work starts after the cluster appears. Open the pages. See whether they answer the same question, support the same question, or only share a brand and a footer.

What the grouping is good for

Once pages are grouped by meaning, a few questions get easier to ask. They are inspection questions, not automatic fixes.

• Where do pages overlap?

  Several URLs sitting in one tight cluster may be covering the same ground. That can be cannibalization. It can also be a legitimate set of supporting pages.

• Where is a topic thin?

  A cluster with one short page and a lot of empty space around it is a different problem than a cluster with eight near-duplicates.

• Which pages are isolated?

  A page that does not sit near the topic it is supposed to support may be written too generically, or it may belong somewhere else.

• Which page would a query actually retrieve?

  If you embed a buyer question and the nearest passages come from a doc, not the commercial page, that is worth knowing before you brief a rewrite.

None of those replace a crawl table. Status codes, canonicals, and indexability still decide whether a page can participate at all. Semantic analysis is the layer on top of that evidence: once the page exists and renders, what is it about, and what else is it sitting next to?

What a cluster cannot tell you

A cluster is a model's neighborhood, not a content strategy.

It does not know intent. Two pages can be close in meaning and still serve different jobs: one ranks for a how-to query, one closes a sale. Combining them because they clustered together is a good way to make both worse.

It does not know demand. Embeddings do not see search volume. A thick cluster can be a topic nobody is asking about. A thin cluster can be the only page that matters.

It does not travel cleanly between models. Change the embedding model and the groups can shift. Change the input — titles instead of passages, nav left in, a different chunk size — and they can shift again.

And it does not prove that retrieval will use a given page. It shows which pages live near each other, and which passages sit near a query you chose to test. The rest is still an SEO reading the evidence.

The next thing we want to measure is the boring one. Take a site whose IA looks tidy, map it, and write down the specific pairs where the folder said "different" and the embeddings said "same." Until we have more of those, the honest claim is smaller: semantic analysis is a useful second map. It is not a substitute for reading the pages.