nestonexTechnical SEO foundations engineering teams actually control
Most of what determines whether a site can rank is decided in the build, by engineers, months before anyone writes a keyword strategy. These are the decisions that matter and the ones that quietly make a site unrankable.
Serve content in the initial HTML, use real links with href attributes rather than JavaScript click handlers, give every page a unique title, description and single descriptive heading, emit structured data that matches what is visible, and treat performance as a build budget rather than an after-the-fact measurement.
Links have to be links
A button with a click handler that changes the route is invisible as a navigation path. A crawler sees an element with no destination, so the page it would have led to is only found if something else links to it. Sites lose whole sections this way without anyone noticing, because the sections still work when you click them.
The rule is simple: anything that navigates is an anchor with an href to a real URL. Keep the JavaScript for the transition if you want the transition; keep the href so the destination exists.
The same applies to primary calls to action. A contact button that only opens a dialog is a dead end for a crawler and for anyone whose JavaScript failed. Make it a link to the contact page that opens the dialog for pointer users, and you have both.
Hash-only navigation has the same problem. In-page anchors are fine as a supplement; they are not a substitute for a URL when the destination is genuinely a separate page.
- Anything that navigates is an <a> with a real href
- Primary calls to action need a destination, not only a handler
- In-page anchors supplement real URLs, they do not replace them
Rendering, and what a crawler actually gets
Search engines can execute JavaScript, but rendering is queued, budgeted and not guaranteed to be complete. Content that only exists after client-side fetching is indexed later, less reliably, and sometimes not at all.
The test takes ten seconds: fetch the page with JavaScript disabled and read what comes back. If the words, the links and the headings are there, you are fine. If the page is an empty div, the page is an empty div as far as a first pass is concerned.
Server-side rendering or static generation for anything meant to be found; client rendering for application routes behind a login where nobody is searching anyway. That split costs nothing to decide at the start and is painful to retrofit.
Content hidden behind interaction is a related case. An accordion whose panels are unmounted until opened has content that does not exist in the document; the same accordion with panels present and hidden using the until-found mechanism does.
Metadata and structure
One unique title per page, written for what someone would search rather than for the brand. One description that earns the click. One heading element that says what the page is for — a brand name in the main heading tells a search engine nothing it did not already know from the domain.
Canonical URLs that point somewhere true, and one per page. Self-referencing canonicals on every page prevent a whole category of duplicate-content confusion from parameters and alternate hosts.
Structured data that matches what is visible. Organization, Service, Article, FAQPage, DefinedTerm and BreadcrumbList where they genuinely apply. Marking up answers a reader cannot see is a penalty waiting to be applied, not a shortcut.
And a sitemap generated from the application rather than maintained by hand, so it cannot drift from what actually exists.
- Unique title, description and one descriptive heading per page
- Self-referencing canonicals, pointing at real URLs
- Structured data that matches the visible content
- A generated sitemap, not a maintained one
Performance as a budget, not a report
Measuring performance after the build tells you what you have; setting a budget during it decides what you get. An image weight ceiling, a JavaScript ceiling, and a rule that content arrives in the initial HTML will do more than any optimisation pass.
The three measured metrics have predictable causes. Largest Contentful Paint is usually the hero image or a render-blocking dependency. Interaction to Next Paint is almost always JavaScript occupying the main thread. Cumulative Layout Shift is images and embeds without reserved space, and fonts that swap metrics.
Field data is the score that counts, and it comes from real visits on real devices across a rolling window. A lab score is for finding causes, not for deciding whether you have a problem.
Which is also why nobody should quote a performance number as a promise. It is measured on someone's machine, and your customer is holding a different one.
Where the build ends and the retainer begins
Everything above belongs in a build. It is architecture, it is cheap to do during development and expensive to retrofit, and no content strategy survives a site that cannot be crawled.
What does not belong in a build estimate: keyword research, content production, link earning and monthly reporting. Those are an ongoing activity with a different cadence, and folding them silently into a project price helps nobody.
Being explicit about that boundary is worth doing in the proposal. It is also a reasonable way to judge a supplier — one who promises rankings as part of a build is describing something they cannot control.
Questions people also ask
Does a single-page application hurt SEO?
Only if the content arrives after the page does. A single-page application with server-side rendering or static generation for its public routes is fine. One that ships an empty shell and fetches everything in the browser is relying on a rendering pass that is queued, budgeted and not guaranteed.
Do buttons really lose you traffic?
Where they are the only route to a page, yes — the destination has to be discovered some other way or it is not discovered. Fetch a page with JavaScript disabled and look at what links remain; anything missing is a page that depends on being linked from elsewhere.
Is structured data worth adding?
Where it describes content that is genuinely on the page, yes. It makes eligibility for richer results possible and gives answer engines a cleaner read of the page. Marking up content that is not visible is a policy violation rather than a shortcut.
How much does performance affect rankings?
Less than relevance and content quality, and more than zero. Treat it as a user-experience requirement with a search side effect: a page that loads slowly or shifts while loading loses people regardless of where it ranked.