Technical accessibility
Pages have to be crawlable, indexable and free of the redirect and canonical conflicts that quietly remove them from search.
ERDNA treats search visibility as engineering work rather than guesswork. It starts with a technically sound website, a clear content structure and pages that answer what people are actually searching for — then the results are measured in Search Console and improved from there.
Keywords describe what people type. They do not explain why one page is served and another is ignored. Search engines evaluate whether a page can be reached, whether it answers the question behind the query, and whether the site around it is coherent enough to be trusted. Modern SEO is the work of getting all of those layers right at the same time.
Pages have to be crawlable, indexable and free of the redirect and canonical conflicts that quietly remove them from search.
Content written for a reader with a real problem outperforms content written to contain a phrase a certain number of times.
A comparison query, a how-to query and a buying query need different pages. Matching the intent matters more than matching the wording.
How pages are grouped and linked tells search engines which topics the site covers and which page is the authoritative one.
Core Web Vitals, render-blocking resources and layout shift affect both how a page is assessed and whether visitors stay on it.
Clear ownership, accurate company information and consistent references build the credibility that rankings are built on.
Schema markup describes what a page is about in a machine-readable form, so it is interpreted the way it was intended.
Readable pages, sensible navigation and working mobile layouts are the difference between a visit and a customer.
The foundation everything else depends on: making sure search engines can reach, read and correctly attribute every page that matters.
Making each page unambiguous — for the person reading it and for the systems deciding when to show it.
A structured review of indexing, site structure, on-page signals, performance, metadata, structured data and Search Console history. You receive a written findings document, each issue rated by impact and effort, and a prioritised action list that can be handed to any developer — or implemented by ERDNA.
Visibility for people searching in a specific place, based on consistent business information rather than volume.
Multilingual sites fail in predictable ways. Getting the structure right prevents language versions from competing with each other.
Schema markup is implemented where it genuinely describes the page — organisation, service, article, breadcrumb, local business or product data — and validated against current specifications. Markup is not added to pages it does not describe, and no rich result is ever promised: how search engines choose to display a page is their decision, not ours.
Google Search Console is set up properly, verified and actually used: monitoring which queries bring impressions, which pages are indexed and which are excluded and why, where clicks are lost to weak titles, and how Core Web Vitals move after a change. Reporting explains what changed and what it means, rather than presenting a dashboard without conclusions.
Finding information no longer means ten blue links. People move between traditional results, maps, video, and increasingly answers assembled by AI-powered systems. That shift changes how visibility works, but it has not replaced the fundamentals — it has raised the cost of getting them wrong.
A site that is easy to crawl, clearly structured, explicit about who is behind it and marked up with accurate structured data is easier for any system to interpret, whether that system is ranking pages or summarising them. Content that answers a question directly, in plain language, is easier to extract than content that circles the point.
What ERDNA will not do is promise outcomes nobody controls. There is no way to guarantee a place in an AI overview, a citation in a chat assistant, or a ranking position. The honest approach is to build a site that is genuinely well described, then measure what actually happens.
What the business sells, who it sells to, which markets matter and what a valuable visitor looks like. Without this, optimisation targets the wrong queries.
A full technical and content review against Search Console data, so decisions are based on how the site is actually being crawled and served rather than assumptions.
Findings are ordered by impact against effort. Issues that block indexing are fixed before cosmetic improvements, and the reasoning is written down.
Changes are made in the codebase — metadata, routing, canonicals, structured data, performance — or handed over as clear specifications for your own team.
Indexing, impressions, queries and Core Web Vitals are tracked after release so the effect of each change is visible, and the next round of work is chosen from evidence rather than opinion.
Launching with a structure that can be found, instead of retrofitting SEO after the first launch.
Being visible for the specific services and locations that bring in enquiries worth answering.
Larger sites accumulate duplicate URLs, orphan pages and legacy redirects that quietly suppress performance.
Application-heavy sites where marketing pages, documentation and rendering strategy all affect indexing.
A redesign is where rankings are most often lost. Redirect mapping and structure planning belong in the build, not after it.
New languages and regions need a deliberate structure so each version reaches the audience it was written for.
Technical fixes can be reflected within days or weeks once pages are recrawled. Changes that depend on content, internal structure and accumulated trust usually take several months to show a stable pattern. Timelines depend on the starting condition of the site, the competitiveness of the market and how much of the plan is actually implemented.
Yes. Most work starts with an existing site. An audit establishes what is already working, what is blocking indexing or performance, and which fixes are worth doing first. A rebuild is only recommended when the current platform genuinely limits what can be achieved.
Not always. A one-off audit and implementation phase is enough for many smaller sites. Ongoing work makes sense when you publish regularly, operate in a competitive market, run several languages, or keep changing the site — because each of those can introduce new issues.
Yes. Multilingual work covers the URL structure for each language, hreflang annotations between versions, self-referencing canonicals, localized page content rather than machine translation, and a sitemap that lists every language version correctly. This page is a working example — see the Estonian version of this SEO page.
Yes. ERDNA builds websites and systems, so recommendations can be implemented directly in the codebase rather than handed over as a document. That includes routing, metadata, canonicals, redirects, sitemaps, structured data and Core Web Vitals work.
No. Nobody can guarantee a position, and any provider who does is worth avoiding. Rankings depend on competitors, search intent and ranking systems that change continuously. What can be committed to is sound technical work, content that matches intent, and honest measurement of what changes.
Access to the website or its codebase, Google Search Console and any analytics you already use, plus a short conversation about your services, target markets and the customers you want to reach. If Search Console is not set up yet, that can be part of the first phase.
Send over your website and what you are trying to achieve, and you will get an honest assessment of what is worth fixing first.