The standard agency workflow: build the site, launch, then hand off to the 'SEO team' who adds title tags and submits a sitemap. By then, the technical decisions that determine ranking — URL structure, page speed, internal linking, schema, Core Web Vitals — are already baked in and expensive to change.
We do it differently. SEO decisions are made at the architecture stage, before a line of code is written. Every component we ship has SEO built in, not bolted on. Here is exactly what that looks like.
1. URL structure designed for search intent
The most expensive SEO mistake is a URL structure you have to change after launch. Every change means redirects, lost link equity, and re-crawling delays.
We plan URL structure before wireframing. Service pages follow a `/services/[category]/[specific-service]` pattern. Blog posts follow `/blog/[descriptive-slug]`. Location pages follow `/[city]/[service]` if the client operates in multiple cities.
Every slug is lowercase, hyphenated, and contains the primary keyword the page targets. No default WordPress slugs like `/p=1234`. No page names like `/about-us-page`. Clean, crawlable, keyword-led from day one.
2. JSON-LD schema on every page type
Schema markup is the language search engines and AI engines use to understand your content without inference. We don't treat it as optional.
Every site we ship includes: Organization schema sitewide (name, url, logo, description, contactPoint, sameAs links to all social profiles), WebSite schema with SearchAction for sitelinks search, Article schema on every blog post (author, datePublished, dateModified, wordCount, image), BreadcrumbList on every page below root level, FAQPage schema on every page with an FAQ section, Service schema on every service detail page with areaServed, offers, and currency.
These are not cosmetic additions. Google's documentation explicitly states that valid JSON-LD markup can trigger rich results in search — FAQ snippets, breadcrumbs, article schemas — which increase click-through rates by 20–30% in our client data.
3. Core Web Vitals as a hard CI requirement
We run Lighthouse CI in our GitHub Actions pipeline. Every pull request is blocked if the build causes any Core Web Vitals metric to drop below threshold: LCP under 2.5s, CLS under 0.1, INP under 200ms.
This sounds extreme. In practice, it forces good habits. Developers can't merge an unoptimised image. Can't add a render-blocking script. Can't introduce a font that causes layout shift. The automated guardrail does the work that would otherwise require a weekly manual audit.
For clients, this means: the site you receive scores 95+ on Lighthouse. Not because we measured it once before launch, but because we structurally cannot ship a regression.
4. Internal linking built into the component architecture
Internal links distribute page authority and help Google understand site structure. Most sites have poor internal linking because it requires every editor to manually add links in every piece of content.
We solve this architecturally. Service pages automatically link to related case studies. Blog posts link to the relevant service page based on category. The footer contains a structured link block to all service categories. The sitemap page (for human visitors) cross-links everything.
None of this requires editor discipline. It's wired into the component props. Change the service name in one config file and every internal link updates across the site.
5. Sitemaps, robots.txt, and AI crawler setup
The sitemap is generated automatically from the route structure using Next.js's `sitemap.ts`. Every published page is included. Draft pages, duplicate routes, and utility pages are excluded. `changefreq` and `priority` are set per page type — blog posts get higher changefreq than the About page.
robots.txt explicitly allows all major AI crawlers: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Applebot-Extended. Sites that don't do this are invisible in AI search interfaces — which now mediate 30–40% of B2B research queries.
We also ship /llms.txt — a plain-text digest of the site for LLM-based search engines — and canonical tags on every page to prevent duplicate content penalties from URL variations.
6. Page speed as a ranking signal — taken seriously
Page speed affects ranking directly through Core Web Vitals, and indirectly through bounce rate (slower pages = higher bounce = less engagement signal for Google).
Every image on a Value Tech site is served as WebP or AVIF via Next.js image optimisation. Fonts are preloaded and subset to only the characters used. Third-party scripts are deferred or loaded after the first user interaction. The Tailwind CSS build ships 5–15KB of CSS per page — not the 500KB that Elementor ships.
The result is a site that loads in under 1.5 seconds on a fast connection and under 3 seconds on a mid-range 4G connection. That's not a vanity metric — it's a ranking input.
What this means for your business
A site built this way doesn't need a 6-month SEO retainer to fix technical issues that should have been right on launch. It starts with a clean technical foundation and grows organic traffic as you add content, rather than fighting against technical debt.
We include all of the above — schema, Core Web Vitals CI, URL architecture, sitemaps, robots.txt, /llms.txt — in every website engagement, including the ₹41,500 starter package. It is not an upsell. It is our minimum standard.
If you want to see this in practice, book a call. We'll audit your current site live on the call and show you exactly where the technical SEO gaps are before you decide whether to work with us.
