What Is JavaScript SEO?
The entire subject reduces to one question you can ask without being technical. Is the content in the page when it arrives, else does something have to run before it appears? Everything else on this page is a consequence of that answer.
One Question Decides Everything
Does the content exist in the page as delivered, else does it have to be assembled first? That single distinction produces every issue in this subject. It is answerable without knowing anything about how sites are built.
What the first case looks like. Everything arrives together.
The words, the links and the structure are in what gets sent. Anything fetching that page has the content immediately, with no further steps and nothing to wait for.
What the second case looks like. A container plus instructions.
What arrives is largely an empty frame with directions for filling it. The content appears once those directions have been carried out, which happens after delivery rather than as part of it.
Why this is the right question rather than a simplification. Everything else follows.
Every symptom below, every diagnostic and every decision traces back to this. Explaining the subject any other way produces a page a business owner cannot act on, which is the usual failure of writing about it.
What this page will not give you. Anything to implement.
No code, no configuration and no framework recommendations. What it gives instead is the ability to establish which situation you are in and to ask the person who built your site a question they have to answer properly.
Why That Matters
Assembling a page takes resource and time. That assembly happens at a different point from the initial fetch. Content depending on it can therefore be seen later than the rest, else not at all.
Two separate events, not one. The core of it.
Fetching a page and assembling a page are distinct operations happening at different moments. A system can complete the first and not yet have done the second, at which point it holds a page whose content is not there.
Why the second step is not guaranteed. It costs something.
Assembly is substantially more expensive than fetching. Anything doing it at the scale of the web has to allocate that expense, so it is a decision rather than an automatic consequence of arriving at a page.
What that means practically. A delay you cannot see.
Content dependent on assembly may be understood later than content that was simply there. On a site changing frequently, later can matter. There is no report anywhere that shows you the gap.
Why this is not a warning about JavaScript. The tool is not the issue.
Enormous numbers of sites use it without any of this being a problem. The issue is only whether content people need to find depends on the second step, which is block seven.
How To Tell Without A Developer
Compare what the page delivers against what you see in a browser. Where the two differ, the difference is the content that depends on something running.
What you are comparing. Delivered against displayed.
On one side, what the site sends when a page is requested. On the other, what a person actually looks at. Those should contain the same material and frequently do not.
What a mismatch tells you. Which side of block one you are on.
If the delivered version contains your headings, your body text and your navigation, you are in the first case. If it is largely empty and the browser view is full, you are in the second.
What to look for specifically. The commercially important parts.
Your main content, your product or service details, your prices where you show them, plus the links to your other pages. Those are what has to be present. Any one of them missing is worth raising.
Why we describe rather than instruct. Deliberate.
The comparison is what matters and the exact route to making it varies. Anybody who builds or maintains sites can make it in a minute once you tell them what you want compared.
The one caveat. Partial is normal.
Almost every modern site assembles something. Finding a difference is not itself a finding. Finding that your main content is in the difference is.
What Commonly Goes Missing
Five recurring cases. Each is described as a symptom to recognise rather than a fault to repair, because the repair is a decision for whoever built the site.
Content loaded on scroll. Present only after movement.
Anything appearing as somebody scrolls depends on that scrolling happening. A system that does not scroll may never reach it.
Tabbed content. Present only after a click.
Material behind tabs may be delivered with the page or may be fetched when the tab is selected. Those are very different situations that look identical to a visitor.
Filtered listings. The ecommerce and property case.
Product or property listings assembled after arrival, where the default view exists and the filtered views do not.
Reviews pulled from a service. Very common.
Review content supplied by a third party is frequently fetched separately. It is visible to customers and absent from what was delivered, which matters because reviews are often the most persuasive material on the page.
Navigation built after load. The serious one.
Menus and internal links assembled rather than delivered. This one is different in kind from the other four and it has its own block below.
Content That Lives Somewhere Else
A great deal of what appears on a modern page is not stored with the page. It lives in another system and is fetched when needed, which introduces a dependency worth understanding.
What that arrangement is. Fetching on request.
The page asks another system for something and displays what comes back. Stock levels, prices, availability, reviews, listings and search results are commonly handled this way. The reasons are usually good ones.
Why it matters here. The content is not in the page.
Anything fetched from elsewhere is by definition not part of what was delivered. It arrives after the request, if the request is made and if the other system answers.
The commonest cause of content being invisible. This one, quietly.
A business assumes its product details are on its product pages. They are on a system the product page asks for them, which is a different thing and one nobody mentions during a build.
Why the other system's behaviour becomes yours. An inherited dependency.
If that system is slow, rate limited or occasionally unavailable, your pages inherit that. This is worth knowing about before it becomes an unexplained pattern in your reporting rather than after.
What is not being said. That this is wrong.
Fetching from elsewhere is normal and frequently necessary. The point is knowing which of your content works that way, because that is the content most likely to be missing.
Links Built By Script
Navigation that only exists after something runs may not be followed. Every other symptom on this page costs you a page. This one can cost you a section.
Why it compounds. Links are how everything is found.
A missing paragraph affects one page. A missing link affects everything that link was the route to, plus everything those pages linked to in turn. The loss multiplies rather than adding.
What it looks like from inside. Completely normal.
The menu works, visitors reach everything and nobody has any reason to suspect a problem. The site functions perfectly for people, which is precisely why this survives so long.
The symptom in your reporting. A section that never appears.
Pages published, live, correct and receiving nothing at all. Not performing badly. Absent. That pattern is worth investigating rather than attributing to competition.
How to confirm it. Look at what was actually requested.
Server records show whether those pages were ever fetched, which distinguishes unreachable from underperforming. That is covered in what is log file analysis in SEO.
Where the general position sits. Our technical material.
How crawling and reachability work generally belongs there rather than here. This page owns only the case where the links do not exist until something runs.
It Is Not A Reason To Avoid Modern Platforms
Plenty of sites built this way perform perfectly well. The issue is how it is implemented rather than the approach itself. The frameworks have addressed a great deal of what used to go wrong.
What changed. The defaults improved.
Modern frameworks now commonly assemble pages in advance by default, which removes the dependency entirely for most content. A site built recently is far less likely to have these problems than one built some years ago.
Why the warnings persist anyway. Advice outlives its conditions.
A great deal of writing on this subject describes a period when the defaults were worse. Repeating it now pushes businesses away from sound decisions for reasons that no longer apply.
What businesses should not conclude. That older is safer.
Choosing a dated platform to avoid a problem that modern defaults have largely solved trades a manageable consideration for a permanent limitation.
The accurate position. Ask rather than avoid.
This is a question to raise during a build rather than a technology to refuse. The architectural choice behind it is covered in server side against client side rendering. The question to ask is the next block.
The Question To Ask A Developer
One question, then three follow-ups. Ask which of our content is present in what the server sends, then which is assembled after the page arrives.
What a good answer sounds like. Specific and unhesitating.
Somebody who knows their build answers immediately and in terms of your actual content. Main text, delivered. Reviews, fetched. Filters, assembled. That is the answer you want and it takes them thirty seconds.
What an inadequate answer sounds like. Reassurance.
Being told it is fine, that search engines handle this now, else that it is not something to worry about. Those may all be true and none of them is an answer to what was asked.
The three follow-ups. Each closes a gap.
Is our navigation in what the server sends. Is our main page content in it. And if anything is assembled afterwards, was that a deliberate choice or a default nobody examined.
Why the last one matters most. It separates two situations.
A deliberate choice has reasons behind it and can be discussed. A default nobody examined is the one worth changing. It is by far the commoner of the two.
What to do with the answers. Nothing hasty.
This is information for a decision rather than a fault list. The full series is on the advanced SEO guide.
Is your content
actually
in the page?
We compare what your site delivers against what a visitor sees, then tell you which of your content depends on something running first. Including whether any section is unreachable rather than uncompetitive. We will tell you plainly if we find nothing worth changing.
What the national tier covers:
The national tier is £1,550 a month. It suits businesses competing beyond one town. We will say so if a lower tier would serve you better.
Every guide.
One practice.
Semantic search, machine learning, topical authority, programmatic production, rendering, log files, crawl allocation, information architecture, content pruning and how strategy changes with scale.
