Website development that passes Core Web Vitals and hands over cleanly

What website development actually is — the part of the site nobody looks at

Website development is the construction of what runs underneath the design: URL structure, content model, templates, render path, caching, tracking layer, forms, security configuration, and code that has to keep working for years. Design decides what a site looks like. Development decides whether it loads, whether a search engine can read it, whether a lead is actually recorded when someone submits a form, and whether the site can still be edited in three years without a rebuild.

This page is not a redesign service and it is not an audit. If your site already exists and underperforms in search, the honest first purchase is diagnosis, not construction — that is technical SEO, a different page with a different deliverable. Website development is for sites that do not exist yet, or that must be rebuilt from the foundation up. We own the construction and the launch event.

A portfolio shows you what a site looks like. It says nothing about the decisions that determine what a site costs to run, or whether it survives contact with search engines, editors and three years of change.

Those decisions are structural and invisible: how URLs are shaped and whether they still work at ten times the page count, what renders on the server versus in the browser, where the cache boundary sits, how analytics events are named before anyone builds a report on them, and what happens on a 404 or a double form submission.

One worked example, because it is the decision that costs the most later. Model a case study as a typed object — client, sector, primary metric, date, related service — and fifteen of them list, filter, cross-link and mark up automatically, with the sixteenth costing almost nothing. Model it as a page with a hand-assembled layout and the sixteenth costs what the first did, none can be listed programmatically, and the day you want “case studies in this sector” you are commissioning a project. That choice is made in week one, is invisible in the mockup, and sets the cost of the site for its whole life.

Design, development and technical SEO — who owns what

Migration is the seam between the second and third rows, so we state how it is split. Our technical SEO service sells migration work in its own right — a migration roadmap, migration SEO, and the redirect-chain audit of a site that already exists — and that is the right purchase when someone else is building the move, or when the damage has already been done. When we run the build, the same roadmap is written inside the project instead: the URL inventory, the single-hop redirect map and the URL parity check at cutover become build deliverables, verified before the old site is retired. Post-launch monitoring and recovery sit with technical SEO either way. It is one piece of work on whichever side of the seam you buy it, scoped once and billed once.

The other boundaries are drawn the same way, so you can tell what you are buying. Conversion infrastructure is ours — forms that submit, events that fire, no dead ends; conversion experimentation belongs to conversion rate optimisation. Responsive implementation is ours; mobile ranking performance belongs to mobile SEO. Building a template that generates pages at scale is ours; using it as a search strategy is programmatic SEO. Emitting valid markup at build time is ours; question inventories and answer architecture belong to AEO.

Why rebuilt sites lose traffic — the six failure modes we build against

The causes of a traffic drop after a rebuild are documented rather than mysterious. All six below are engineering failures, which is what makes all six preventable at build time instead of recoverable afterwards.

1. URLs change and nothing redirects. Google’s guidance on a site move with URL changes is explicit that every old URL must point at its new equivalent. We inventory every live URL, map it one-to-one before cutover, and ship single-hop 301s — no chains, no blanket redirect to the homepage.
2. Metadata is dropped with the old templates. Titles, descriptions, canonicals, hreflang and structured data live inside the templates being replaced. We extract them as data and re-import them as data.
3. Content is quietly shortened. Copy gets tightened in the rebuild and the paragraphs that were doing the ranking disappear. We diff content page by page and flag every material reduction before launch.
4. Pages are orphaned. A page survives migration but loses every internal link pointing at it. We compare the internal link graph old against new and reconcile the difference.
5. Performance regresses. The new build ships heavier than the one it replaced and field data degrades over the following weeks. A performance budget is enforced as a launch gate, not a post-launch fix.
6. Everything changes in one week. Design, URLs, platform, content and hosting move together, so nothing is attributable afterwards. Where the calendar allows we sequence the changes and record what changed on which date.

What we build

1. Information architecture and URL design

Section taxonomy, the content model and its typed fields, the URL pattern and how it behaves as the site grows, canonical and breadcrumb logic, pagination rules, and an internal linking model written as a rule rather than added by hand. This prevents the site that works at forty pages and becomes unmaintainable at four hundred.

2. Platform selection and CMS implementation

This decision starts with what the site has to do, not with what we prefer to build. A content-led site that is editorially maintained, with forms, a blog and templated service or location pages, suits a mature open-source CMS, and the one we build on is WordPress: bespoke theme code and first-party plugin code, not a marketplace theme with a page builder stacked on top. It is the wrong choice when the site is really an application with accounts and transactional state, when a security policy prohibits a plugin-extensible CMS, or when the editorial team is one person who will never touch nine tenths of it. We will say so — and we do not sell a platform migration to a client whose platform is fine.

3. Responsive implementation

Responsive is a defined technique set — fluid layout, flexible media, container and media queries, breakpoints derived from content rather than device names, touch targets sized for hands — not an adjective. The detail that matters most: the mobile experience is not a subset. Same content, same structured data, same internal links, same conversion paths, laid out differently.

4. Performance engineering against field data

The build is engineered to the Core Web Vitals thresholds, with the qualification that a pass is judged on real users in the Chrome UX Report, not on a lab score from one run on one machine. That changes what you build: image dimensions and formats fixed at template level so nothing shifts while loading, fonts loaded without a layout jump, third-party scripts budgeted and deferred rather than accepted one at a time, caching and server response configured rather than assumed, and a page-weight budget a new marketing tag has to be argued past.

5. Technical-SEO and schema readiness at build time

Crawlable, indexable and machine-readable on day one: server-rendered primary content and links, because Google’s JavaScript SEO guidance makes client-side rendering a search decision taken at build time; real robots and sitemap configuration; canonical and pagination handling in the templates; structured data emitted from template code rather than pasted into a plugin field. Markup must describe what the page actually displays, which is what Google’s structured data policies require — and why this is schema readiness, not a schema strategy.

6. Analytics, consent and conversion infrastructure

An event taxonomy agreed before implementation, so reports are not rebuilt six months later; a tag container deployed and versioned; conversion events wired to what is worth money — form submissions, calls, quote starts, downloads — and verified firing before launch; bot protection on forms; and a consent implementation whose categories genuinely gate tag behaviour rather than only record a click. India’s DPDP framework requires notice and consent rather than any particular interface, so the three-category UI is our implementation choice, not a legal requirement we are quoting at you. The failure mode here is expensive: a beautiful new site that has quietly recorded nothing for a quarter.

7. Security and maintainability

Response headers set at the edge, dependencies pinned and updatable, roles scoped so an editor cannot break a template, an admin surface that is not the default one, backups restored once as a test rather than assumed, and a build reviewed against the OWASP Top 10 rather than described as “secure”. Maintainability is the same discipline aimed at the future: fewer dependencies, documented fields, code another developer can read.

The launch gate — what we accept as the definition of done

We define “done” in writing before the project starts, so that it is not settled by argument at cutover. Each item below names the external standard it is judged against, which makes it a check rather than a claim — and something you can hold us to.

Two honest limits travel with that gate. Field Core Web Vitals cannot be confirmed on launch day, because field data is a rolling 28-day window of real users; the real answer arrives about a month after cutover, and what the gate confirms is the lab measurement and the template-level causes. And conformance with WCAG 2.2 at level AA is claimed for the templates and components we ship, not for content published later — an inaccessible PDF uploaded in month six is a governance problem, not something a build can guarantee in advance.

What you own at launch, and what happens if you leave

• The domain is registered in your account, in your legal entity’s name.
• Hosting is in your account and billed to you. We hold access, not ownership.
• The analytics property and tag container belong to your Google account, with us added as a user you can remove in one click.
• The repository and all theme and plugin code written for you is yours — no licence back to us, no obfuscated files.
• Administrator credentials are handed over at launch. Not after the final invoice, not on request.
• No proprietary page builder, and no licence key that stops working when the relationship does.
• A written architecture note at handover: content model, custom fields, scheduled jobs, third-party integrations — so the next developer starts by reading rather than reverse-engineering.

We publish this because it is what the procurement and IT side of a buying group asks, and it is cheaper to answer once in writing than on every call.

Evidence: what we built to run this site

Instead of a logo wall, here is the build you are reading — measured on 7 September 2026, reproducible by you in browser dev tools on this domain.

• A bespoke theme at wp-content/themes/seoindia and a first-party plugin at wp-content/plugins/seoindia-core: application code, not a purchased theme with a builder on top.
• Three plugins render the homepage — hostinger-reach, litespeed-cache and our own seoindia-core. Every plugin is a dependency somebody has to keep updated for the life of the site.
• Structured data emitted from template code — ten types on the homepage (Organization, WebSite, WebPage, FAQPage, SearchAction, SpeakableSpecification, ContactPoint, PostalAddress, ImageObject, EntryPoint) plus twelve Question and twelve Answer nodes.
• Six security headers: Strict-Transport-Security with includeSubDomains, X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin, a Permissions-Policy disabling geolocation, microphone, camera and interest-cohort, and Content-Security-Policy: upgrade-insecure-requests — plus explicit Cache-Control in front of a page cache.
• Twelve interactive tools with server-side integrations, not brochure pages.
• Five custom post types; 149 location pages from one template; 37 service pages, 28 industry pages and 15 case studies on typed templates.
• Bot-protected forms, and a three-category consent interface (essential, analytics, marketing) wired to actual tag behaviour.

Two caveats that reduce the claim. This is our own site, built without a client’s legacy estate, existing martech contracts or inherited brand system — a build inside those constraints will not be this lean, and we would rather say so now than at week six. And all of it is read from server-delivered HTML and response headers: it describes what is configured, not how fast the site is for real users. We publish no Core Web Vitals figure for this domain here, because we have not measured one for publication. Run it yourself with our PageSpeed tool and judge the result rather than the adjective.

What we do not build, and when this is the wrong purchase

We do not build native iOS or Android applications. We do not build Shopify or Magento stores — we do search work on those platforms, and platform SEO for an existing store, such as WooCommerce SEO, is a separate service with a separate scope. There is no framework wall here, and no logo strip or project-count figure, because nothing is published on this page that we cannot show you.

Three situations where you should not buy this. If your site is structurally sound and simply underperforming in search, buy diagnosis first — rebuilding is the most expensive possible way to discover the problem was six templates and an internal linking model. If you have traffic that is not converting, that is testing, not construction. If you need many more pages from an existing template, that is a content and search play rather than a build.

And one real trade-off, stated plainly: the gate costs you time. A build that must clear a verified redirect map, a performance budget, an accessibility pass and an analytics parity check before cutover launches later than one that goes live the day the design is approved. If an immovable external date governs your launch, something has to give — and we would rather name in writing which gate items were deferred than quietly drop them and call the launch clean.

Questions buyers ask

What is the difference between website design and website development?

Website design and website development answer two different questions. Design decides what a site looks like and how it behaves for a person: layout, hierarchy, typography, interaction states, and the prototype that gets signed off. Development builds the working system underneath — content model and URL structure, the templates that turn data into pages, the render and caching path, analytics and conversion tracking, security configuration, and the migration and launch. Design output is a specification; development output is a site that loads, ranks, records leads and can be maintained. Most projects need both, and a good design implemented badly loses search traffic just as reliably as a poor one.

Will our search rankings drop when we rebuild the site?

Rankings can drop when a site is rebuilt, and the causes are documented rather than mysterious: URLs changed without a redirect map, metadata lost with the old templates, content shortened during the rebuild, pages orphaned from internal links, a performance regression, and too many variables changed at once. Each is an engineering failure preventable at build time, which is why URL parity and a complete single-hop redirect map are named build deliverables verified before cutover rather than repairs made afterwards. Nobody can honestly promise that no individual query will move. What can be promised is that the rebuild itself is not the cause.

How much does website development cost, and what changes the price?

We do not publish a website development price, and we will not quote a range that has no relationship to your project. The price is set in a written proposal after scope, and five things move it most: the number of distinct templates (not the number of pages), how many existing URLs must be inventoried and mapped, whether content is written or migrated, the number of third-party integrations, and how many custom interactive features exist beyond forms. The only prices we publish anywhere are for ongoing managed programmes, which are a separate commitment from a build — see our pricing page.

How long does a build take from start to launch?

A website development build follows a fixed sequence even when the calendar does not: discovery and information architecture, then the content model and templates, then build, then content migration and the URL map, then the launch gate, then cutover with a monitored window afterwards. We do not publish a standard duration on this page, because two things determine elapsed time far more than development effort — how quickly content and approvals come back from your side, and how many existing URLs must be inventoried, mapped and verified. That is why the schedule we agree names your deadlines as well as ours, and why the dated version appears in the written proposal, once the template count and the URL inventory are known.

Who owns the code, the domain, the hosting and the analytics after launch?

You own the code, the domain, the hosting account and the analytics property after a build we deliver. The domain is registered in your legal entity’s name, hosting is in your account and billed to you, the analytics property and tag container sit in your Google account with us added as a removable user, and the repository containing all theme and plugin code written for the project is yours with no licence back to us. Administrator credentials are handed over at launch, and handover includes a written architecture note covering the content model, custom fields, scheduled jobs and integrations. If you move to another agency they inherit a documented site rather than a puzzle.

Can we edit content ourselves without calling a developer?

You can edit content on a site we build without calling a developer, and whether that is true of any site is a build decision rather than a training problem. Pages are assembled from typed, named fields with defined constraints, so an editor changes text, an image or a list item without being able to break the layout or delete a template, and roles are scoped so the person writing blog posts cannot alter site structure. The trade-off is deliberate: a tightly modelled site gives you less freedom to invent an arbitrary new layout in the editor than a free-form page builder does, and in exchange it stays consistent and structurally sound after two years of edits by people who were not there at launch.

Will the new site actually pass Core Web Vitals?

A site we build is engineered to pass Core Web Vitals, and the thresholds sit in the launch gate rather than in an aspiration — but a pass is judged on field data from real users in the Chrome UX Report over a rolling 28-day window, so nobody can confirm a field pass on launch day. What the gate confirms is the lab measurement and the template-level causes of failure: image dimensions and formats fixed in the templates, fonts loaded without layout shift, third-party scripts budgeted and deferred, caching and server response configured. A site that passed at launch can still fail months later because tags were added afterwards without a budget, which is why the page-weight budget is part of handover.

Next steps

If you are rebuilding, the useful first conversation is about your existing URL inventory and what has to survive the move: bring your current site and analytics access, and we will tell you what the migration risk looks like before anyone discusses design. If you are starting from nothing, the first conversation is about the content model, because that decision sets the cost of everything after it. Either way you get a scoped written proposal with the launch gate above written into it as the acceptance criteria.