Website design vs website development: where the boundary sits
Website design is the decision layer of a website: information architecture, page templates, a type and colour system, interaction states, responsive behaviour and accessibility conformance. It ends in specifications — wireframes, a design system, annotated states and acceptance criteria — that a developer implements. Website development is the build layer that turns those specifications into working code. Most buyers need both.
The line between the two is easy to leave vague, and vagueness is what scope arguments are made of later. So we publish the boundary. The same table will be published on the website development page when that service goes live, so neither engagement can quietly claim the other’s work.
| Decision | Design owns | Development owns |
|---|---|---|
| Page templates | How many exist, what each must contain, acceptance criteria | Reusable components, every breakpoint verified |
| Type and colour | The scale, the contrast ratios, the fallback stack | Font delivery, font-display, preload behaviour |
| Accessibility | Focus order, focus styling, target sizes, contrast, labels, error copy | Semantics, ARIA only where native HTML cannot do the job, keyboard testing |
| Performance | The budget: hero weight, image dimensions, post-paint movement | Meeting the budget in code, then measuring it in the field |
| URL structure | The inventory and the redirect map, written before any visual work | Server-side implementation, one hop per URL, verified |
| Content | Word-count ranges, heading hierarchy, the shape each block must fill | Making those blocks editable without a developer |
Short version: design decides and specifies, development builds and verifies. If you already have a design system you are happy with and you only need it built, you are buying development, not design.
The accessibility failures are design failures, and they are measured
WebAIM’s 2026 Million study ran automated accessibility testing across one million home pages. 95.9% of them had detected WCAG 2 failures, at an average of 56.1 errors per page. Six error categories accounted for 96% of everything found — and every one of the six is settled at design time, before a line of code is written.
| Error category | Pages affected | Decided by |
|---|---|---|
| Low contrast text | 83.9% | Colour palette |
| Missing alternative text | 53.1% | Content model |
| Missing form input labels | 51.0% | Form design |
| Empty links | 46.3% | Icon and CTA design |
| Empty buttons | 30.6% | Icon and CTA design |
| Missing document language | 13.5% | Template setup |
The honest caveat: automated testing catches only a subset of WCAG failures. Keyboard traps, illogical focus order, unusable error recovery and meaningless alt text mostly pass automated checks. So 95.9% is a floor, not a ceiling, and it does not mean 95.9% of sites are “inaccessible” — it means detected failures were present. Read the study yourself at WebAIM Million.
The standard we design to, stated precisely
We target WCAG 2.2 Level AA, the current W3C Recommendation. We name 2.2 rather than 2.0 for a specific reason: 2.0 is a 2008 document that predates the success criteria most modern mobile failures fall under — target size, focus appearance and dragging movements. That is not the same as saying 2.0 is dead; W3C is explicit that 2.2 does not deprecate 2.1, and 2.1 does not deprecate 2.0. If your procurement paperwork names 2.0, we conform to 2.0 and design to 2.2 anyway, because the extra criteria are the ones your phone users hit.
GIGW 3.0: the India-specific gate almost no design page mentions
If you are an Indian government department, a PSU, or a vendor bidding into public-sector procurement, the applicable document is GIGW 3.0, the Guidelines for Indian Government Websites and Apps published by the National Informatics Centre under MeitY. We read the current GIGW text against your tender clauses before design starts, because a template that fails a GIGW checkpoint at UAT is a rebuild, not a revision. We deliberately do not print a WCAG level or a checkpoint count for GIGW here: those numbers circulate in secondary blog posts, and we verify against the primary document per project instead.
Website redesign without losing SEO rankings or traffic
A redesign does not lose traffic because the new design is worse. It loses traffic because URLs moved without redirects, because templates stopped emitting a single clear H1 or title, because internal links were re-cut, because body copy moved into components that never render into the DOM, or because a staging noindex shipped to production. Every one of those is decided before launch, which is why the protocol runs in this order and why visual work does not start until steps one and two exist.
1. URL inventory before the first wireframe
We export every indexable URL from the sitemap, the server, and analytics, then classify each as keep, merge, or retire. A URL that earns traffic is a constraint on the new information architecture, not an afterthought for the developer. Pages nobody can find in that inventory are the ones that quietly disappear on launch day.
2. A redirect map written by the designer, not the developer
Every retired or merged URL gets a one-hop 301 to its closest equivalent page, not a bulk redirect to the homepage. The map is a deliverable you review and sign before visual design begins, because it is the map that decides how many templates you actually need.
3. Template-level parity checks
For each template we check that the new design still emits a single H1, a title pattern that matches or improves on the old one, the same or richer internal link paths out of the body, and the same crawlable text. A “cleaner” design that moves body copy into a tab, an accordion that ships collapsed with its content removed from the DOM, or a hero image standing in for an H1 are the three failure modes this check exists to catch.
4. Staging discipline and the launch window
Staging stays behind HTTP authentication rather than relying on noindex alone, so the tag can never ship to production by accident. We take a pre-launch measurement snapshot, launch on a low-traffic day, and hold a comparison window afterwards. We do not promise rankings will not move — they always move a little — we promise the movement is measured against a baseline captured before anything was touched, and handed to technical SEO for diagnosis if it does not recover.
Performance is a design constraint, not a plugin
Google’s Core Web Vitals thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, at the 75th percentile of real visits and reported separately for mobile and desktop. INP replaced FID as a stable Core Web Vital in 2024, which matters here because INP punishes heavy interaction work — mega-menus, filter panels, carousels — that a design decision put there in the first place. We treat the three numbers as budgets handed to the build:
- LCP: the hero element is chosen at design time. A full-bleed video or a 2MB stock photograph is a decision to fail LCP on a mid-range Android on a 4G connection.
- CLS: every image, embed and ad slot is specified with intrinsic dimensions so space is reserved before the asset loads. Late-loading webfonts get a metrics-matched fallback so text does not reflow.
- INP: interactions are designed to be cheap. If a filter needs 400ms of JavaScript to repaint a grid, the design is what needs revising.
Measurement, field data and repair belong to technical SEO, and the mobile-first indexing consequences belong to mobile SEO. This page owns only the decisions that make those numbers achievable in the first place.
Conversion-focused design, judged against a named method
We evaluate layouts against Nielsen Norman Group’s ten usability heuristics rather than against adjectives. Three of the ten are the ones we check first on lead-generation and ecommerce layouts, because each names a specific, findable defect: visibility of system status (a form that submits with no confirmation), error prevention (a phone field that rejects a valid number on blur without saying why), and recognition rather than recall (a checkout that hides the total until the final step).
On checkout and lead flows, Baymard Institute’s synthesis of 50 studies puts documented average cart abandonment at 70.22%. Excluding people who were only browsing, three of the six leading reasons are pure design and flow decisions: forced account creation (18%), a checkout that is too long or complicated (17%), and site errors or crashes (17%). Extra costs revealed late (40%) is a design decision about disclosure timing as much as a pricing one.
What we will not do is attach a conversion-lift percentage to a redesign. 70.22% is an abandonment rate observed across studies, not a recovery promise, and anyone quoting you “we increase conversions 40%” before seeing your funnel is quoting a number they cannot own. Structured testing of variants is a separate discipline — see conversion rate optimisation.
Responsive and accessible design decisions, named
Breakpoints we design at, not just resize to
We produce composed layouts at 360px, 768px, 1024px and 1440px, and we test the awkward widths in between rather than assuming fluid CSS will cope. 360px is our narrowest composition width by choice: a layout composed at 390px and then squeezed is a layout nobody has actually looked at at 360px.
Interaction states that get designed, not improvised
Every interactive element ships with six specified states: default, hover, focus-visible, active, disabled and error. Visible focus is non-negotiable and is never removed for aesthetics. Touch targets are specified at 44×44 CSS pixels minimum with spacing between them — that figure is our own floor, not a quotation from the standard.
Media, alt text and the content model
Alt text is a design deliverable, not a developer’s guess. Every image slot in the design system is classified as informative (needs alt text, written by us with your input), decorative (ships with an empty alt attribute), or functional (alt text describes the action, not the icon). Because Google indexes the mobile rendering, any content the mobile layout hides from the DOM is content you have chosen not to be indexed on.
What “delivered” means, and who owns it
The artifact list is in the capabilities panel on this page. Two things about it are worth saying here, because they are what an artifact list cannot show.
Every item is a named file, not a description. “Complete design package” means nothing and is unenforceable. A redirect map is a spreadsheet with old URL, new URL, status code and reason, signed off before any visual work starts. A design system is a file with a type scale, colour tokens carrying measured contrast ratios, and every component in all six states. If a deliverable cannot be handed over as a file with a name, it is not a deliverable — it is a claim.
Ownership, stated in the open: when the final invoice is paid, you own the design files, the exported assets and the source code produced for you, outright and irrevocably. We keep no licence hostage and we do not host your files in an account you cannot access. Third-party licences — fonts, stock photography, plugins — are listed separately with their terms, because those are licensed to you by their owners, not by us.
What we can commit to, what we can observe, and what we cannot
Website design is a new service line at SEOIndia. Everything on this page is the method and the commitment, not a record of past design projects — and a page that argues for measurement should be the last place to imply a track record it cannot show you.
- We can commit to: every artifact in the capabilities panel, delivered as a named file; WCAG 2.2 AA conformance targets checked per template; the redirect map completed and signed off before design starts; and design files handed over in editable form with ownership transferred.
- We can observe but not guarantee: field Core Web Vitals after launch, since those depend on hosting, third-party scripts and your visitors’ devices. We set the budget; the build and the stack decide the field result.
- We cannot promise: a ranking position, a conversion-rate increase expressed as a percentage, or that no URL will fluctuate after a redesign. We also cannot publish an average delivery time as measured data, because we have not measured one across a sample large enough to publish honestly. What we do instead is write the scope band into the statement of work and hold ourselves to it.
When a redesign is the wrong thing to buy
If your templates are structurally sound and your problem is that specific pages underperform, do not buy a redesign. Buy an SEO audit first and fix what it names. A redesign is the most expensive way to solve a problem a diagnosis would have located in a week. Equally, if your problem is that nobody can find your pages rather than that visitors dislike them, start with technical SEO. And if the pages look fine but say nothing, the constraint is content strategy, not layout. We would rather sell you the smaller engagement and keep the relationship.
Questions buyers ask before signing
How long does a website redesign take from start to finish?
A website redesign is scoped into contractual bands rather than quoted as an average: roughly three to five weeks for a five-to-ten page site, eight to twelve for ten to twenty, twelve to sixteen for thirty to seventy-five, and sixteen to twenty-four beyond a hundred, plus two to four weeks between contract and kickoff. Those are the bands written into the statement of work and held to, not a measured average of past projects — we have not measured one across a sample large enough to publish. What moves a project between bands is rarely the page count. It is the number of distinct templates — twenty pages built from three templates is a smaller job than eight pages that are all different — and it is review latency, which is the part of the schedule the client controls rather than the agency. That is why the number of review rounds and the deadline for each are fixed in the statement of work rather than left open: an unbounded review cycle is the single most common reason a redesign misses its date.
Will a redesign hurt my current rankings or traffic?
A redesign can damage rankings, but almost never because the visuals changed. Traffic is lost when URLs move without one-hop 301 redirects, when templates stop emitting a single clear H1 or title, when internal links are re-cut so important pages lose their paths, when body copy is moved into components that do not render into the DOM, or when a staging noindex tag ships to production. Each of those is preventable with a URL inventory and a redirect map completed before design starts. Expect some fluctuation after launch while the new pages are recrawled — we do not publish a recovery window as a number, because we have not measured one across a sample large enough to publish honestly — and expect a baseline measurement taken before launch so you can tell fluctuation from damage.
What is the difference between website design and website development?
Website design is the decision and specification layer: information architecture, templates, type and colour systems, interaction states, responsive behaviour, and accessibility conformance, delivered as wireframes, a design system and acceptance criteria. Website development is the build layer that turns those specifications into working, tested code with a content management system your team can edit. If you have no agreed design system, you need design first, because development without specifications produces a site nobody can extend. If you already have a design system you are happy with, you need development only.
Who owns the design files and the source code when the project ends?
On a SEOIndia website design engagement, you own the design files, exported assets and the source code produced for you outright once the final invoice is paid, with no ongoing licence from us and no lock-in. Third-party components are the exception: fonts, stock photography and commercial plugins remain licensed to you directly by their vendors under their own terms, and we list every one of them with its licence in the handover so you know exactly what transfers and what is rented. Ask any agency to state this in writing before you sign; the ones that will not are telling you something.
Who writes the copy, me or the agency?
Copy for a website design project can come from you, from us, or from a written content brief we produce together, and website design specifies the shape it has to fill: word-count ranges per block, heading hierarchy, and what each section must accomplish. Designing against filler text is how pages end up unable to hold real sentences, so the rule on our projects is to design against final copy or a written brief, never against lorem ipsum. Copy production at scale is a separate engagement; see content strategy.
Can my own team edit the site after handover?
Your own team can edit the site after handover, and that editability is specified during design rather than bolted on at the end. Each template records which regions are editable, which are locked, and the content rules for each — maximum heading length, image aspect ratio, whether a section can be reordered or removed. Handover includes the design system file, the content matrix and a walkthrough. The constraint worth knowing before you ask for more freedom is that a fully free-form editor makes the design system easy to break, which is why we lock structure and open content.
How many revision rounds are included, and what counts as a revision?
A SEOIndia website design engagement includes two structured revision rounds per deliverable stage — one at wireframes, one at composed design — with consolidated feedback from your side in a single document per round. A revision is a change within the agreed scope and direction. A change of direction after sign-off, added templates, or new functionality is a scope change quoted separately, and we say so at the moment it happens rather than in the final invoice. Fixing anything that fails our own acceptance criteria — contrast, focus states, breakpoints, heading order — is not a revision and is never billed.
Next step
The first deliverable is not a proposal, it is a measurement. We audit your current site against the WCAG 2.2 AA criteria automated testing can reach, check contrast across your existing palette, list the templates you actually have, and pull the URL inventory. You get that document whether or not you engage us, and it tells you whether you need a redesign, a repair, or something else entirely. Ask us for the design audit when you want it, or start with conversion rate optimisation if the layout is broadly right and only the funnel is leaking.