Why the frontend affects search traffic
A common story in Tashkent: an agency or freelancer builds a polished site in React or Vue, the owner starts running ads on Instagram and Telegram, and yet the pages never show up in Google. The content exists and the design is fine, but the crawler receives almost empty HTML and either postpones processing or understands only part of the page.
Fixing this after launch costs more than planning for it, because you end up changing the rendering approach, the URLs and the templates. That is why SEO requirements are best agreed before layout work begins, not after it.
Frontend SEO starts with rendering
The key question for sites on modern frameworks is whether the content sits in the initial HTML or only appears after JavaScript runs. Google can render scripts, but it does so with a delay and not always completely. Other search engines, social media bots and AI assistants cope noticeably worse.
For pages that need to appear in search, pick one of the reliable options:
- server-side rendering (SSR): HTML is built on the server for each request
- static generation (SSG): pages are prepared ahead of time during the build
- hybrid modes in Next.js and Nuxt: a different approach per page type
- pure client-side rendering is fine for customer accounts and admin panels, but risky for catalogues, service pages and articles
Links, URLs and response codes
Navigation between pages must use real links with an href attribute. If your menu works through a click handler on a div, a crawler will not get past the home page. Pagination follows the same logic: a “Load more” button is convenient for shoppers, but a catalogue also needs links to separate list pages, otherwise products deep in the list go unnoticed.
Keep URLs readable, in Latin letters, without unnecessary parameters and with one consistent trailing-slash format. One page, one address. A page that does not exist should return a 404 code rather than an empty template with a 200 code, a frequent flaw in single-page apps. Set up redirects on the server.
Meta tags and language versions
Every page needs its own title, description and canonical, meta robots where relevant, and Open Graph tags, which generate the preview when someone shares a link in Telegram. These values should arrive in the server-rendered HTML rather than being injected by a script after load. In single-page apps the tags must also update when the route changes, which is regularly forgotten.
If your site runs in Russian and Uzbek, keep each version on its own URL, for example /ru/ and /uz/, with hreflang tags and ordinary links in the language switcher. A language chosen only by cookie or browser setting leaves the crawler with one version instead of two.
Images and mobile speed
Many customers browse on phones, often on unstable mobile internet, so speed is not a formality. The frontend carries much of the responsibility for the three Core Web Vitals:
- LCP: load the main first-screen element, usually a banner, early and without lazy loading
- INP: reduce JavaScript volume and long tasks, and load third-party scripts later
- CLS: reserve space for images, banners and fonts with width and height
- img tags with meaningful alt text, srcset for different screens, modern formats and compression
- lazy loading only for images below the first screen
- skip heavy libraries that exist only for minor visual effects
Structured data and a pre-launch checklist
Generate JSON-LD from your templates on the server: Organization on the home page, BreadcrumbList on inner pages, Product on product cards, Article in the blog. Pull the data from the same sources as the visible content, otherwise the markup drifts away from what people actually see. Before release, confirm that:
- content is visible in the page source without running scripts
- each template has a unique title, description and H1
- links are real, response codes are correct and a 404 page exists
- robots.txt and sitemap.xml are generated and do not block the site
- no noindex is left over from the test version
- Core Web Vitals look healthy on mobile in a lab test
- structured data passes validation
How to work with an SEO specialist
Ask for technical requirements before layout starts: a list of templates, meta tag fields, the URL format and markup needs. Show a test version before launch so the specialist can run it through a crawler. This order saves time and budget otherwise spent on rework.
The markdev team handles SEO optimisation in Uzbekistan and can help write these requirements or review a build before release. If your site runs on a JavaScript framework and you are unsure whether search engines can see it, describe the task and we will work out what to change first.
FAQ
Does every React or Vue site need SSR?
For pages that must be found in search, yes: SSR or static generation is more dependable. Customer accounts and admin panels can stay client-rendered.
How can I quickly check whether a crawler sees my content?
Open the page source and look for headings and text. If you only find an empty container and script tags, the content is built in the browser and the page is at risk.
What is a soft 404?
It happens when a missing page displays a “not found” message but the server responds with a 200 code. Search engines may treat such URLs as normal pages and fill the index with them.
Who is responsible for SEO: the developer or the marketer?
The SEO specialist leads strategy and content, while the developer builds the technical foundation. Results are best when requirements are agreed before development starts.
Let’s look at your task for free
Leave your contact — in a 15-minute call we’ll show where leads get lost and what to fix first.