# websitedevelopment.biz — full text

> The complete text of every guide in this language, so an answer engine can read the catalogue in one request. Nothing here is absent from the visible pages.

## When to Redesign Your Website (and When Not To)
https://websitedevelopment.biz/guides/when-to-redesign-your-website
Updated 2026-08-07 · Maintenance

Redesigns are frequently launched for the wrong reason — the site looks dated to the people who see it every day — and they carry real risk: a full rebuild resets accumulated search signals, discards conversion knowledge, and often replaces a known problem with an unknown one.

This guide covers what genuinely justifies a redesign, what does not, and the incremental route that produces better results on most sites.

### Reasons that justify a redesign
These are structural problems that cannot be fixed by changing pages, which is what makes them redesign reasons rather than improvement reasons.
- The platform is end of life or no longer receives security updates.
- The site is not responsive and cannot be made so without a rebuild.
- The structure no longer matches the business — you sell something the information architecture cannot express.
- Editing is impossible without a developer, so content is stale by default.
- Performance is structurally poor because of how it was built, not because of a few large images.
- Accessibility failures are in the components themselves and cannot be patched.
- A merger or rebrand changes the name, not only the colours.
Notice what is not on this list: "it looks dated". That is usually a styling project, and styling projects are a fraction of the cost and carry almost none of the risk.

### Reasons that do not
Each of these has a cheaper, lower-risk fix that addresses the actual problem.
| "It looks dated" | Visual style | Restyle: typography, colour, spacing |
| "Traffic is falling" | Content or technical issue | Diagnose first — a redesign usually makes it worse |
| "Conversions are low" | Specific pages or a form | Test changes to those pages |
| "A competitor relaunched" | Nothing measurable | Not a reason |
| "New marketing director" | Ownership, not the website | Review the data together first |
| "It is three years old" | Age is not a defect | Fix what is measurably wrong |

### Why full redesigns often lose traffic
A full redesign changes structure, content, URLs and templates simultaneously. If performance drops, you cannot tell which change caused it — and if it improves, you cannot tell either.
- URL changes lose accumulated signals unless every redirect is mapped correctly.
- Content rewritten "to be more concise" frequently removes the exact text that was ranking.
- New templates can drop internal links, structured data or metadata that the old ones had.
- Design changes can reduce conversion in ways that only show up weeks later.
- Everything changes at once, so attribution afterwards is guesswork.
If a redesign is genuinely necessary, keep the URL structure and the ranking content wherever you can. Change the appearance and the code, not the addresses.

### The incremental alternative
For most sites, a series of targeted changes outperforms a rebuild — it is cheaper, it is measurable, and each step can be reversed.
- Measure first: analytics, Core Web Vitals, Search Console, and a handful of user sessions.
- Fix performance and accessibility on the existing templates. These usually pay for themselves.
- Rewrite the pages that get traffic but do not convert, one at a time.
- Restyle: typography, colour, spacing. This addresses "looks dated" for a fraction of the cost.
- Replace individual templates one by one, keeping their URLs.
- Improve the editing experience so content stops going stale.
- Re-measure after each step, so you know which change did what.

Q: How often should a website be redesigned?
A: There is no correct interval. A well-maintained site that is improved incrementally can run for many years without a rebuild. The trigger should be a structural problem you cannot fix within the current build, not a date on a calendar. Sites redesigned every three years by policy usually lose ground each time.

Q: Will a redesign improve my SEO?
A: Not by itself, and it can easily hurt. What helps is what a redesign sometimes includes: faster pages, better structure, better content. Those improvements can be made without a redesign, with less risk. If search performance is the goal, diagnose the actual cause before committing to a rebuild.

Q: Should I keep my URLs in a redesign?
A: Wherever you possibly can. Keeping URLs removes the single largest risk in a relaunch. If they must change — a genuinely broken structure, or a domain change — map every old URL to a specific new one with a 301 and keep those redirects indefinitely.

Q: How long does a redesign take?
A: Similar to a new build, and often longer because of migration: two to five months for a mid-sized site. It is rarely cheaper than starting fresh once content migration, URL mapping and matching existing behaviour are counted, which surprises most people who expect a discount for having a site already.

## Website Monitoring: Knowing Before Your Customers Do
https://websitedevelopment.biz/guides/website-uptime-monitoring
Updated 2026-08-07 · Maintenance

Uptime monitoring answers one question: does the homepage respond? Most real failures are quieter than that. The site is up and the contact form has been failing for three weeks, or checkout works for everyone except customers using one payment method.

This guide covers what to monitor, how to set thresholds that mean something, and how to keep alerts credible.

### Beyond "is it up"
The failures that cost money are usually partial. Monitor the outcomes you care about, not only the server responding.
| HTTP uptime | Server down, DNS failure | Every 1–5 minutes |
| Transaction check | Broken form, broken checkout | Every 15–60 minutes |
| Error rate | Exceptions rising after a deploy | Continuous |
| Certificate expiry | The classic Sunday-morning outage | Daily, alert 30 days out |
| Domain expiry | The worst possible outage | Daily, alert 60 days out |
| Core Web Vitals | Slow degradation nobody notices | Weekly |
| Search Console coverage | Pages dropping out of the index | Weekly |
| Disk and database size | Silent growth into a hard limit | Daily |
| Backup success | Backups that stopped running months ago | Daily |
A synthetic transaction that submits a real form to a test address is the single highest-value monitor for most business sites. Broken forms are invisible and expensive.

### Setting thresholds that mean something
A monitor that alerts on every blip trains people to ignore it, and then it does not work when it matters. Thresholds should reflect what would actually make you act.
- Require two or three consecutive failures before alerting, from more than one location.
- Alert on error rate rather than on individual errors — a single 500 is noise, a rate change is a signal.
- Set performance alerts on a trend over days, not on one slow measurement.
- Separate severities: site down goes to a phone; a slow page goes to a weekly summary.
- Route alerts to a person, not to a shared inbox nobody owns.
- Review every alert that fired: if it required no action, either change the threshold or delete the monitor.

### What to do when an alert fires
Having a written order of operations turns an incident from improvisation into a procedure, which matters most when the person on call is not the person who built the site.
- Confirm it is real: load the site yourself from a different network.
- Check the obvious first — did anything deploy, did a certificate expire, is the host reporting an incident?
- Post a status update if customers are affected. Silence is worse than bad news.
- Restore service before diagnosing. Roll back the deploy, then investigate at leisure.
- Write down what happened, why, and what would have caught it earlier.
- Add the monitor that would have caught it. That is how the list above grows correctly.
The most useful output of an incident is one new monitor and one fewer way for it to happen silently.

### Sensible defaults for a small site
You do not need an observability platform. For most business websites this set is enough and takes an afternoon to configure.
- Uptime check on the homepage and on one deep page, every five minutes, from two locations.
- A synthetic form submission daily, to an address a human reads.
- Certificate and domain expiry alerts, well in advance.
- Server error alerting from the application, with a rate threshold.
- A weekly email with Core Web Vitals and Search Console coverage.
- A daily confirmation that the backup ran and its size looks normal.

Q: How often should I check uptime?
A: Every one to five minutes is standard, from at least two geographic locations so a network problem at one monitoring node does not page you at 3am. More frequent checks rarely change the outcome, because the time to notice is small compared with the time to fix.

Q: What uptime should I expect?
A: Decent shared hosting delivers around 99.9%, which is roughly nine hours of downtime a year. Managed platforms and good cloud setups reach 99.95% or better. What matters more than the number is whether the downtime is scattered minutes or a single long outage during business hours.

Q: Are free monitoring tools sufficient?
A: For uptime on a small site, generally yes — the free tiers cover a handful of checks at five-minute intervals. What free tiers usually lack is synthetic transactions and multi-step checks, which is exactly where the valuable monitoring is. Budget a small amount for those specifically.

Q: How do I avoid alert fatigue?
A: Delete monitors that have never required action, require multiple consecutive failures before alerting, and separate urgent from informational routing. Then review fired alerts monthly. An alert channel people mute is worse than no alerting, because it creates the belief that someone is watching.

## Website Backup Strategy: What to Back Up and How Often
https://websitedevelopment.biz/guides/website-backup-strategy
Updated 2026-08-07 · Maintenance

Most sites have backups. Fewer have backups that have been restored. The gap between the two is discovered at the worst possible moment, usually alongside the discovery that the backup was missing the database, or the uploads, or the last three weeks.

This guide covers what to back up, how often, where to keep it, and how to verify that a restore actually works.

### What a complete backup contains
A site is not one thing. Missing any of these makes a restore partial, and a partial restore is often worse than none because it looks like it worked.
- Database — content, users, orders, settings. The part that changes constantly.
- Uploaded files — images, documents, anything users or editors added.
- Application code — ideally in version control, which is a form of backup with history.
- Configuration — environment variables, server config, cron jobs, redirect rules.
- Certificates and DNS records — cheap to export, painful to reconstruct under pressure.
- Third-party settings — payment webhook URLs, email configuration, API keys.
Configuration is the part most often missed. A restored database and file set on a server configured differently is not the same site.

### How often, and how long to keep
Frequency follows from one question: how much work can you afford to lose? Retention follows from another: how long before you would notice a problem?
| Static brochure site | Weekly | Weekly | 30 days |
| Business site with a blog | Daily | Daily | 30–60 days |
| Busy content site | Daily, or hourly | Daily | 60–90 days |
| Online store | Hourly or continuous | Daily | 90+ days, and keep monthly archives |
| Web application | Continuous with point-in-time recovery | Daily | Per your data policy |
Retention matters because slow-moving problems exist. A corrupted import or a quiet compromise may not be noticed for weeks, by which time a 7-day rotation contains only bad copies.

### Where to store them
The classic rule still holds: three copies, on two kinds of media, with one off-site. Adapted for websites, it means the backup must survive both the server failing and the server being compromised.
- Never store the only copy on the same server as the site.
- Use a different provider for at least one copy, so a provider-level failure does not take both.
- Make at least one copy immutable or write-once, so credentials that run the site cannot delete it.
- Encrypt backups at rest — they contain everything, including personal data.
- Keep a monthly archive outside the rotation for slow-discovery problems.
- Document where they are and how to restore, somewhere that is not only on the site.

### Testing: the step that makes it real
A backup you have never restored is an assumption. Testing takes an hour and converts it into a fact.
- Restore to a separate staging environment, not over the live site.
- Check the database restored completely — count rows in the tables that matter.
- Check uploaded files are present, including recent ones.
- Log in and perform a real task: publish a page, place a test order.
- Time it. "How long would a restore take?" is a question you want answered in advance.
- Write down the procedure so it is not held only by the person who set it up.
- Repeat monthly, and after any change to the hosting setup.
Time the restore. Knowing it takes four hours changes what you promise stakeholders during an outage, and it is the number nobody has when they need it.

Q: Is my host’s backup enough?
A: It is a good baseline and a poor sole strategy. Host backups typically have short retention, are stored on the same infrastructure, and are lost along with the account if there is a billing dispute or a provider failure. Keep your own copy somewhere else — the cost is small and it is the copy you will need in the scenario where host backups do not help.

Q: How long should I keep backups?
A: Long enough to cover a slow-discovery problem. Thirty days is a reasonable minimum, ninety is safer for a store, and a monthly archive kept for a year costs almost nothing. Balance that against data protection obligations — backups containing personal data are subject to retention rules too.

Q: Do I need backups if my code is in version control?
A: Yes. Version control covers code and its history, and it does not contain the database, the uploaded files or the server configuration. Those are where the content and the customer data live, which is the part that cannot be recreated by re-running a deployment.

Q: What is point-in-time recovery?
A: The ability to restore the database to any moment, rather than to the last scheduled snapshot — achieved by continuously archiving the transaction log. It matters when losing even an hour of orders is unacceptable. For a brochure site it is unnecessary; for a store taking orders through the night it is worth the extra setup.

## Website Security: The Practices That Prevent Most Incidents
https://websitedevelopment.biz/guides/website-security-best-practices
Updated 2026-08-07 · Maintenance

Most website compromises are not targeted. They are automated scanners finding a known vulnerability in outdated software, or a reused password on an admin account. Defending against the ordinary attacks covers the large majority of real risk.

This guide covers the practices that prevent most incidents, in rough order of effect, and what to do if a site is already compromised.

### The measures that prevent most incidents
In order of how much risk they remove per unit of effort.
- Keep software current. The overwhelming majority of compromises exploit a vulnerability with an available patch. This single item outweighs everything below it.
- Unique strong passwords plus two-factor authentication on every admin account, hosting panel, domain registrar and email account.
- Least privilege. Editors do not need administrator accounts. Remove accounts when people leave.
- HTTPS everywhere, with HSTS once you are confident every subresource is available over TLS.
- Tested backups, stored off the server. A backup on the compromised machine is encrypted along with everything else.
- Restrict the admin area by IP where practical, and always rate-limit login attempts.
- Remove what you do not use. Every inactive plugin, theme and old install is attack surface with no benefit.
Old, forgotten installs — a staging copy at /old, a test blog in a subfolder — are a common entry point precisely because nobody is updating them.

### Input, output and the classic vulnerabilities
These are developer responsibilities and they account for most of the vulnerabilities that are not "you did not update".
| SQL injection | Reads or destroys your database | Parameterised queries, always — never string concatenation |
| Cross-site scripting | Runs attacker script in a visitor’s session | Escape on output, contextually; a strict Content-Security-Policy |
| Cross-site request forgery | Performs actions as a logged-in user | Per-session tokens on every state-changing request |
| File upload abuse | Uploads and executes code | Validate type by content, store outside the web root, never execute |
| Broken access control | Users reach data that is not theirs | Check authorisation server-side on every request, not in the UI |
| Sensitive data exposure | Leaks keys and credentials | Environment variables, never in the repository |
| Server-side request forgery | Makes your server call internal systems | Allow-list outbound destinations |

### Configuration and headers
Cheap measures that close whole categories of problem, most of which take minutes to apply.
- Serve security headers: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options.
- Disable directory listing; make sure /.git, /.env and backup files are not reachable over HTTP.
- Turn off verbose error output in production — stack traces are reconnaissance.
- Block access to admin and configuration paths from the public internet where you can.
- Set cookies with HttpOnly, Secure and an appropriate SameSite value.
- Keep dependencies audited; a vulnerable library in your build is your vulnerability.
- Log authentication events and alert on unusual patterns.

### If the site is already compromised
Order matters here. Cleaning files before rotating credentials means the attacker simply returns through the same door.
- Take the site offline or into maintenance mode. Do not leave it serving malware to visitors.
- Preserve evidence: copy the logs and a snapshot of the files before changing anything.
- Rotate every credential — hosting, database, admin users, API keys, email. Assume all are known.
- Restore from a backup taken before the compromise, if you can identify one reliably.
- If you cannot, rebuild from source and re-import only data, never files of unknown origin.
- Patch the vulnerability that let them in. Without this step you will repeat the whole process.
- Scan for persistence: scheduled tasks, extra admin users, modified core files, injected content.
- Request a review in Search Console if the site was flagged, and check for injected spam pages.
- Notify affected users if personal data was exposed — in many jurisdictions within a legal deadline.
Restoring a backup without patching the entry point is the most common reason sites are compromised twice in a fortnight.

Q: Is a security plugin enough?
A: It helps with a few things — login rate limiting, file change monitoring, a basic firewall — and it is not a substitute for updates, strong credentials and least privilege. A site with a security plugin and eighteen months of missed updates is not secure. Fix the fundamentals first, then add tooling.

Q: Do small websites really get attacked?
A: Constantly, and not because of who you are. Automated scanners test every reachable host for known vulnerabilities; small sites are attractive precisely because they are less likely to be patched. Compromised small sites are used for spam, phishing pages and redirects, which is why the traffic level of your site is irrelevant to the risk.

Q: Where should backups be stored?
A: Somewhere the web server cannot write to, ideally with a different provider, with at least one copy that cannot be deleted by the same credentials that run the site. Ransomware and destructive attacks specifically target backups reachable from the compromised machine, and that is exactly the moment you need them.

Q: What is the single highest-value security measure?
A: Applying updates promptly. It is unglamorous and it prevents more real compromises than everything else combined, because the attacks that actually happen are automated exploitation of known, patched vulnerabilities. Second is two-factor authentication on admin and hosting accounts.

## Website Maintenance: What It Actually Involves
https://websitedevelopment.biz/guides/website-maintenance-guide
Updated 2026-08-07 · Maintenance

Website maintenance is the work that keeps a site secure, current and working after launch. It is invisible when it is done and extremely visible when it is not — usually as an outage, a compromise or a form that has been silently failing for a month.

This guide covers what maintenance actually includes, what it costs, what a retainer should specify, and how to verify you are receiving it.

### What the work is
Maintenance splits into routine work on a schedule and responsive work when something happens. A retainer that only covers the second is not maintenance, it is support.
| Security patches | As released, within days | Known vulnerabilities are exploited automatically |
| Platform and plugin updates | Monthly, tested on staging | Falling behind makes upgrading harder every month |
| Backup verification | Monthly restore test | An untested backup is not a backup |
| Uptime monitoring | Continuous | You should not learn about downtime from a customer |
| Error log review | Weekly | Silent failures — broken forms, failed payments |
| Performance check | Monthly | Page weight rises quietly as content is added |
| Broken link check | Quarterly | External links rot at a steady rate |
| Content review | Quarterly | Stale prices and dead phone numbers cost more than bugs |
| Dependency audit | Quarterly | Abandoned libraries need replacing before they break |

### What it costs
A useful planning figure is 10–20% of the build cost per year for a CMS-based site, more for a store or an application. Below that you are usually buying availability rather than actual work.
| Small brochure site | $50 – $200 | Updates, backups, uptime monitoring, minor edits |
| Mid-size business site | $200 – $800 | The above plus staging tests, performance and error review |
| Online store | $500 – $3,000 | The above plus payment and stock monitoring, faster response |
| Web application | $1,500+ | The above plus release management and on-call |
A cheap retainer with no report is difficult to distinguish from no retainer at all. The report is what you are actually buying.

### What a retainer should specify
Vague retainers cause disputes at exactly the wrong moment. These points should be written down before you sign.
- Exactly which routine tasks are performed and how often.
- Response time targets, split by severity: site down, feature broken, cosmetic.
- Cover hours, and what happens outside them.
- How many hours of changes are included, and whether unused hours roll over.
- What counts as a change versus a new project, with examples.
- Who has access to what, and how that is revoked when the arrangement ends.
- What you receive monthly: an actual report, not an invoice.
- Notice period and what happens to your data and access at the end.

### Doing it yourself
For a small site this is entirely reasonable, provided it is scheduled rather than intended. Put it in a calendar with a named owner, because maintenance done "when we remember" is not done.
- Weekly: check the site loads, submit the contact form, glance at error logs.
- Monthly: apply updates on staging first, then production. Verify a backup restores.
- Monthly: check Search Console for new coverage errors and manual actions.
- Quarterly: run a link checker, a performance test and an accessibility scan.
- Quarterly: review content for prices, dates, staff names and dead links.
- Annually: review domain and certificate renewals, and audit who still has access.
Set calendar reminders with a named person, not a team. Shared responsibility for a recurring chore reliably becomes nobody’s responsibility.

Q: What happens if I skip maintenance?
A: For a while, nothing visible — which is why it gets skipped. Then one of three things happens: a known vulnerability is exploited by an automated scanner, an update becomes impossible because you are several major versions behind, or something has been broken for weeks and nobody noticed. All three cost more than the maintenance would have.

Q: Can I use my hosting provider’s maintenance package?
A: Managed hosting usually covers the server, and often core platform updates and backups. It rarely covers your plugins, your custom code, your error logs or your content. Read what is included; the gap between "managed hosting" and "site maintenance" is where most incidents happen.

Q: How do I know maintenance is being done?
A: Ask for a monthly report: what was updated, what was patched, uptime, errors found and fixed, and the date of the last successful backup restore. If a retainer produces no report, you cannot distinguish good maintenance from none — and you usually find out which it was during an incident.

Q: Should updates be applied automatically?
A: Security patches for the core platform, generally yes — the risk of delay usually exceeds the risk of breakage. Plugin and major version updates should be tested on staging first, because those are the ones that break layouts and custom code. The right split depends on how much the site is worth per hour of downtime.

## eCommerce SEO: The Practices That Actually Matter
https://websitedevelopment.biz/guides/ecommerce-seo-best-practices
Updated 2026-08-07 · eCommerce

Store SEO differs from content SEO in one important way: the site generates URLs by itself. Filters, sorting, variants and pagination can turn a 500-product catalogue into 50,000 indexable pages, and that is where most store SEO problems begin.

This guide covers how to structure a store so the right pages rank and the machine-generated ones stay out of the index.

### Categories are your most valuable pages
Most commercial search demand is for a category, not a specific product: people search for "waterproof walking boots" far more than for a particular model. Category pages are therefore the pages worth investing in, and they are usually the thinnest.
- Give each category real text — a short introduction above the grid and useful detail below it.
- Match the category to how people search, not to how your warehouse is organised.
- Link related categories to each other; a grid of products with no editorial links is a dead end.
- Keep category URLs stable even when the range changes. The URL outlives the products in it.
- Show enough products above the fold that the page answers the query immediately.
A category page with no text is competing on product titles alone. That is why category pages so often lose to content sites reviewing the same products.

### Faceted navigation: the main source of trouble
Filters multiply URLs combinatorially. Left open, they consume crawl budget, dilute signals and fill the index with near-duplicates that are slow to remove.
| Base category | Index, self-canonical |
| Single high-demand filter (e.g. brand) | Index if there is real search demand and enough products |
| Multiple filters combined | noindex, follow |
| Sort order | noindex, or do not create a distinct URL at all |
| Pagination | Index, each page self-canonical, real crawlable links |
| Empty filter result | noindex, and consider returning a 404 |
| Tracking parameters | Strip, or canonicalise to the clean URL |

### Product pages: URLs, variants and stock
Three decisions here cause most product-page problems, and all three are cheaper to settle before launch.
- One URL per product, not one per category path. A product in three categories should not exist at three URLs.
- Variants: one indexable product page with variant selection, unless a variant has genuinely distinct demand — colour rarely does, size never does.
- Out of stock: keep the page live with availability marked and alternatives shown. Deleting it discards accumulated ranking signals for a product that may return next month.
- Discontinued permanently: 301 to the closest equivalent or to the category, not to the homepage.
- Unique descriptions. Manufacturer text is on every competitor’s site; it is the definition of duplicate content.
- Structured data with price and availability that match the visible page exactly.

### Technical items specific to stores
These come up on almost every store and rarely on a brochure site.
| Internal search results | noindex — they are infinite and thin |
| Basket and checkout | noindex, and block from crawling |
| Customer accounts | noindex; never allow indexing of order pages |
| Multiple currencies | One canonical URL; do not create a URL per currency |
| Multiple markets | Prefix URLs plus reciprocal hreflang |
| Reviews | Render in HTML; review markup only for genuine on-page reviews |
| Listing performance | Watch it as the catalogue grows — it degrades first |
| Sitemaps | Split by type, and keep them current as stock changes |
Product feeds for shopping ads are not a substitute for indexable product pages. They are separate systems and one does not rank the other.

Q: Should out-of-stock products be removed?
A: Not if the item is coming back. Keep the page, mark availability accurately in both the visible page and the structured data, and offer alternatives. Deleting it throws away links and ranking history you paid for. Only 301 it when the product is genuinely discontinued, and then to the nearest equivalent rather than the homepage.

Q: How do I handle products in several categories?
A: Give each product a single canonical URL that does not include the category path — /products/walking-boot-x rather than /boots/walking/walking-boot-x. Link to it from every relevant category. Category-based product URLs create duplicates and break as soon as you reorganise the catalogue.

Q: Do I need unique descriptions for every product?
A: For products you want to rank, yes. Manufacturer copy appears on every competitor selling the same item, so there is nothing to distinguish your page. If a full rewrite of 4,000 products is unrealistic, start with the products that actually drive revenue and let the rest rely on category pages.

Q: Should filter pages ever be indexed?
A: A small number, deliberately chosen: single filters that match real search demand and return a decent number of products, like a brand within a category. Give those pages their own title and description. Everything else — combinations, sorts, price sliders — should be noindex, follow.

## Payment Gateway Integration: What Developers Need to Get Right
https://websitedevelopment.biz/guides/payment-gateway-integration-guide
Updated 2026-08-07 · eCommerce

Payment integration looks simple in a tutorial and is unforgiving in production, because every failure case involves either a customer who paid and got nothing or a customer who got something and did not pay.

This guide covers how the flow works, the design decision that prevents most problems, and the cases worth testing deliberately before launch.

### How the flow actually works
Whatever the provider, the shape is the same: your server creates an intent to charge, the customer authenticates with the payment provider, and the provider tells you the outcome — twice, by two different routes.
- Your server creates a payment intent with an amount, currency and a reference to your order.
- The customer enters card details in a hosted field or a hosted page, so the data never touches your server.
- Strong authentication may be required, adding a step the customer must complete.
- The provider redirects the customer back to your site with a result.
- Separately, the provider sends a server-to-server webhook with the authoritative result.
- Your system updates the order — from the webhook, not from the redirect.
- Fulfilment is triggered only after the payment is confirmed.
Steps 4 and 5 are the whole design. The redirect is a hint about what happened; the webhook is the fact.

### Why webhooks must be the source of truth
The customer's browser is an unreliable narrator. It can close during the redirect, lose connection, or be manipulated. If your order status depends on the customer arriving back at your success page, you will have paid orders that were never recorded.
- Update order state only from verified webhooks; treat the redirect purely as a user-facing message.
- Verify webhook signatures. An unauthenticated endpoint that marks orders paid is exactly as bad as it sounds.
- Make webhook handling idempotent — providers retry, and duplicates will arrive.
- Respond quickly and process asynchronously; slow endpoints get retried and eventually disabled.
- Log every webhook payload. Payment disputes are settled with logs.
- Handle events out of order, because they can and will arrive that way.

### The failure cases worth testing
Each of these happens in production. Test them deliberately, with the provider’s test cards, before launch.
| Customer closes the tab after paying | Webhook still completes the order; confirmation email is sent |
| Card declined | Clear message, basket preserved, another attempt possible |
| Strong authentication failed | Order not confirmed; customer told what to do next |
| Duplicate webhook | Order updated once, not twice; no second dispatch |
| Webhook arrives before the redirect | Success page reflects the already-completed order |
| Partial refund | Order totals and any accounting export stay consistent |
| Stock ran out between payment and fulfilment | Defined process: refund, backorder or substitute |
| Currency rounding | The charged amount matches the displayed total exactly |

### Scope, compliance and money
A few decisions determine how much regulatory burden you take on and how much of the transaction you keep.
- Never store card numbers. Use hosted fields or a hosted page so card data never reaches your server; this keeps PCI scope minimal.
- Understand the fee structure. Percentage plus fixed fee, plus currency conversion, plus chargeback fees. The headline percentage is not the cost.
- Check payout timing. Days to settlement affects cash flow more than a small rate difference.
- Confirm the refund path works end to end before launch, including partial refunds.
- Support the local methods your market actually uses — cards are not the default everywhere, and missing the dominant local method costs conversions.
- Keep a second provider ready if payments are critical. Outages happen and they stop revenue entirely.

Q: Should I use a hosted checkout or an embedded form?
A: Hosted checkout is simpler, keeps PCI scope smallest, and is maintained by the provider — for most stores it is the right default. Embedded fields keep the customer on your domain and give more control over the experience, at the cost of more code and more responsibility. Both keep card data off your server, which is the part that matters.

Q: What happens if my webhook endpoint is down?
A: Providers retry with backoff, typically for hours or days, so a short outage recovers by itself. A long outage means orders sitting unconfirmed, so monitor the endpoint and alert on failures. Also build a reconciliation job that compares provider transactions against your orders daily — it catches everything the retries missed.

Q: Do I need to handle strong customer authentication?
A: If you sell to customers in regions that require it, yes, and modern provider SDKs handle most of the flow. What you must handle is the outcome: an order that is pending authentication is not paid, and treating it as paid means shipping goods you were never paid for.

Q: How do I test payments safely?
A: Every provider has a test mode with cards that trigger specific outcomes — decline, authentication required, fraud. Run the full list, including the awkward cases in the table above. Then make one small real transaction in production before launch and refund it, because test mode does not exercise your live keys or your live webhook URL.

## WooCommerce vs Shopify vs Magento: A Practical Comparison
https://websitedevelopment.biz/guides/woocommerce-vs-shopify-vs-magento
Updated 2026-08-07 · eCommerce

These three cover most store projects, and they suit genuinely different situations. The choice is less about features — all three can sell products — and more about who maintains the store and what happens when requirements grow.

This comparison is by operating model rather than by feature checklist, because that is what determines whether a platform works out.

### Who each one is for
Stated plainly, before the detail.
| Shopify | Hosted SaaS | Teams who want to sell, not to maintain infrastructure |
| WooCommerce | WordPress plugin, self-hosted | Content-led sites with a modest catalogue and WordPress skills |
| Magento / Adobe Commerce | Self-hosted enterprise | Complex catalogues, B2B rules, in-house or agency capability |

### Practical differences
The comparisons that change the decision, rather than the ones that appear on marketing pages.
| Setup effort | Low | Medium | High |
| Who patches security | The vendor | You | You |
| Checkout customisation | Limited by design | Full | Full |
| Catalogue at scale | Good | Degrades without work | Built for it |
| B2B pricing rules | Add-on | Plugin, variable quality | Native |
| Multi-store / multi-market | Additional cost | Awkward | Native |
| Running cost | Subscription plus fees plus apps | Hosting plus plugins plus dev time | Substantial hosting and dev time |
| Skills needed | Operator | WordPress developer | Specialist developer |

### Where each one breaks
Every platform has a failure mode that appears after launch rather than during evaluation. These are the ones that come up most.
- Shopify: checkout rules the platform will not permit, and app subscriptions that eventually exceed the platform fee. Also, transaction fees if you do not use its own payment product.
- WooCommerce: listing-page performance as the catalogue grows, plugin conflicts after updates, and security exposure when nobody owns patching.
- Magento: total cost of ownership. It is powerful and it needs real infrastructure and real expertise; under-resourced Magento stores are slow and fall behind on updates.
- All three: faceted navigation generating thousands of indexable URLs unless it is configured deliberately.
The most common expensive mistake is choosing Magento for a catalogue that WooCommerce would handle, or choosing WooCommerce for one that needs Magento. Both errors surface about a year in.

### Exit costs
Worth knowing before you commit, because it is the part that decides whether the choice is reversible.
| Shopify | CSV export, straightforward | Export without passwords | Export, limited history | Fixed URL prefixes make mapping fiddly |
| WooCommerce | Full database access | Full access | Full access | Fully under your control |
| Magento | Full database access | Full access | Full access | Fully under your control |
Self-hosted platforms are easier to leave because you have the database. That is a genuine advantage of open source and it is rarely weighed at selection time.

Q: Which is cheapest?
A: For a small store, Shopify is usually cheapest in total once hosting, patching and developer time are counted — the subscription is visible and the alternative costs are not. WooCommerce is cheapest if you already run WordPress and have someone competent maintaining it. Magento is not the cheap option in any scenario.

Q: Is WooCommerce good for large catalogues?
A: It can handle thousands of products with proper hosting, caching and query work, but it needs that work — performance on listing and filter pages degrades before the product count sounds impressive. If the catalogue is large and complex from day one, it is worth comparing against platforms built for that shape.

Q: Do I need Magento for B2B?
A: Not necessarily, but B2B requirements — customer-specific pricing, quotes, purchase orders, account hierarchies — are native there and are add-ons elsewhere. If you have several of those requirements, the comparison is fair. If you have one, an add-on on a simpler platform is usually cheaper to own.

Q: Can I run content and commerce on the same platform?
A: WooCommerce does this naturally because WordPress is a content system first. Shopify’s content tooling is weaker, so content-heavy Shopify stores often pair it with a separate CMS. If your acquisition strategy is content-led, weigh that seriously — it is a bigger practical difference than most feature comparisons suggest.

## eCommerce Platforms Compared: How to Choose
https://websitedevelopment.biz/guides/best-ecommerce-platforms-compared
Updated 2026-08-07 · eCommerce

Platform comparisons date fast because features change every quarter. What does not change is the set of questions that decide which category of platform fits, and the trade-offs each category makes.

This guide compares the categories rather than the brands, and gives the questions that narrow the choice quickly.

### The four categories
Almost every option falls into one of these, and the category decides more than the brand within it.
| Hosted SaaS | Content and operations only | Most small and mid-sized stores |
| Self-hosted open source | Everything: hosting, updates, security | Unusual requirements, in-house capability |
| CMS plugin (e.g. a shop plugin) | The whole stack, lightly | Content-led sites with a modest catalogue |
| Headless commerce | The front-end, and the integration layer | Multiple channels, custom experiences, larger teams |

### The questions that actually narrow it
Answer these before looking at any feature list. Most of them eliminate whole categories rather than individual products.
- How complex is a single product? Variants, configurable options and per-customer pricing rule out the simplest tools.
- How many markets? Multiple tax regimes and currencies are where cheap platforms become expensive.
- What must it integrate with? An existing ERP or accounting system is usually the deciding constraint.
- Who runs it day to day? A platform requiring a developer for routine changes is the wrong fit for a two-person business.
- What is the realistic order volume in two years? Transaction fees scale in a way monthly fees do not.
- What happens if you leave? Ask how you export products, customers and orders before you sign anything.
The exit question is the one nobody asks and the one that hurts most later. A platform with poor export tooling is a decision you cannot revisit cheaply.

### Total cost, not licence cost
Hosted platforms look expensive on the subscription line and often cheaper overall once hosting, security and maintenance are counted. Self-hosted looks free and is not.
| Subscription | Monthly, tiered by volume | None |
| Transaction fee | Often a percentage on top of payment fees | Payment fees only |
| Hosting | Included | Yours, and a store needs real resources |
| Security and PCI | Largely handled | Yours, including scope |
| Updates | Automatic | Yours, and can break customisations |
| Apps and extensions | Monthly per app, adds up quickly | Usually one-off or free, plus your time |
| Developer time | Lower for routine work | Higher, ongoing |

### Where each category breaks
Knowing the failure mode is more useful than knowing the feature list, because you will meet it in year two rather than in the demo.
- Hosted SaaS: a checkout requirement the platform will not allow, or app subscriptions quietly exceeding the platform fee.
- Self-hosted: nobody applies the security updates, and the store is compromised or falls badly behind.
- CMS plugin: catalogue growth degrades performance, and the site was never built for commerce-scale queries.
- Headless: the front-end team becomes a bottleneck for changes the marketing team used to make themselves.
Almost every one of these is an operational failure rather than a technical one. Choose the platform your organisation can actually run, not the most capable one.

Q: Is open source cheaper than a hosted platform?
A: Rarely, once you count hosting, security patching, developer time and the cost of an incident. It is cheaper when you have in-house capability that would otherwise be idle, or when you have requirements a hosted platform refuses. Comparing the subscription line to zero is the mistake that makes it look obvious.

Q: Can I move platforms later?
A: Yes, and it is a full project — typically 30–50% of the cost of a new build once catalogue migration, URL mapping and integration rework are counted. That is why the export question belongs in the selection process. Products usually export cleanly; customers and order history are where it gets difficult.

Q: What about headless commerce?
A: It is genuinely useful when you sell across several channels or need a front-end the platform cannot produce, and it is significant extra complexity otherwise: you own the front-end, the integration layer and their deployment. For a single-channel store with a normal catalogue it usually buys flexibility you will not spend.

Q: Which platform is best for SEO?
A: They are broadly comparable now — the differences are in how much control you have over URLs, canonicals and metadata, and in front-end performance. What matters more is whether your implementation handles faceted navigation, pagination and product URL stability properly, and that is a build decision on every platform.

## eCommerce Website Development: The Complete Guide
https://websitedevelopment.biz/guides/ecommerce-website-development-guide
Updated 2026-08-07 · eCommerce

An online store is a website with money, stock and legal obligations attached. That is what makes eCommerce website development a different project from a brochure site: the parts that cost the most are usually not the ones customers see.

This guide covers what a store project actually includes, what drives the cost, the operational work that starts at launch, and the mistakes that are expensive to unwind.

### What a store includes beyond the shop front
The catalogue and checkout are the visible part. Underneath sit the systems that decide whether the business can actually operate, and they are where most of the budget goes on any store beyond the smallest.
- Catalogue structure: categories, variants, attributes, bundles, availability rules.
- Pricing: tax-inclusive or exclusive by market, discounts, customer groups, currency.
- Payments: at least one gateway, plus refunds, partial refunds and failed-payment handling.
- Shipping: zones, weights, dimensions, carrier rules, free-shipping thresholds.
- Tax: VAT or sales tax by destination, invoices with the fields your jurisdiction requires.
- Stock: availability, backorders, and reservation during checkout so you do not oversell.
- Order management: where staff process orders — often a separate system entirely.
- Emails: confirmation, dispatch, refund, abandoned basket, and their legal content.
- Returns: the policy and the workflow that implements it.
Ask early where staff will actually process orders. If it is your existing ERP, integration is a substantial part of the project and belongs in the first estimate.

### What drives the cost
Product count matters less than product complexity and the number of systems the store has to talk to.
| Catalogue | Simple products, one price | Variants, configurable options, per-customer pricing |
| Markets | One country, one currency | Multiple tax regimes, currencies, languages |
| Integrations | None beyond payment | ERP, PIM, WMS, accounting, marketplace feeds |
| Migration | New store, no history | Existing catalogue, customers, orders and URLs |
| Fulfilment | One warehouse, flat shipping | Multiple locations, carrier rules, dropshipping |
| Compliance | Standard consumer sale | Age restriction, licensing, regulated goods |

### Migration is a project of its own
Replatforming an existing store is usually harder than building a new one, and the difficulty is data and URLs rather than design.
- Export and clean the catalogue before anything else. Existing data is always worse than remembered.
- Decide what does not move. Discontinued products with no traffic do not need migrating.
- Map every old product and category URL to a new one; 301 them, and expect this list to be long.
- Migrate customer accounts without passwords — force a reset rather than moving hashes between systems.
- Decide how much order history moves. Often the answer is "none, keep the old system read-only for a year".
- Run both systems in parallel for a short window if stock allows, and reconcile daily.
- Watch search traffic per category for six weeks; a category that drops is usually a redirect that was missed.
Budget as much time for catalogue data cleaning as for building the store. On most migrations it is the larger task and the one nobody planned for.

### The work that starts at launch
A store is an operating system for a business, not a project that finishes. These costs are ongoing and are frequently missing from the first budget.
| Product content | New lines, new photography, new descriptions |
| Stock accuracy | Overselling costs more than any development bug |
| Payment and platform updates | Gateways deprecate APIs on their own schedule |
| Security patching | Stores are a payment-data target; patches are not optional |
| Fraud and chargebacks | Rules need tuning as the mix of orders changes |
| Tax rule changes | Rates and thresholds change by jurisdiction, sometimes annually |
| Performance | Catalogue growth degrades listing pages first |

Q: How much does an online store cost to build?
A: A small store on a hosted platform with a light theme can start around $5,000. A mid-sized store with a custom design and one or two integrations is typically $20,000–$60,000. Large catalogues with ERP integration and multiple markets run well beyond that. Migration usually adds 30–50% to an equivalent new build.

Q: Hosted platform or self-hosted?
A: Hosted platforms handle security, PCI scope and scaling for a monthly fee and often a transaction percentage, at the cost of customisation limits. Self-hosted gives full control and you own the maintenance and the compliance burden. For most small and mid-sized stores hosted is the lower-risk choice; the argument for self-hosted grows with unusual requirements and revenue.

Q: Do I need a separate order management system?
A: Below a few dozen orders a day the platform admin is usually enough. Above that, or with multiple sales channels, a dedicated system pays for itself quickly. The question to answer before the build is where the authoritative stock number lives, because that decides which system tells which.

Q: What is the most common eCommerce build mistake?
A: Treating tax and shipping as configuration rather than as requirements. They are business rules with edge cases — thresholds, zones, mixed baskets, digital goods — and discovering them in week eight rewrites the checkout. Get them written down during discovery, with examples of the awkward cases.

## SEO-Friendly URL Structure: Rules That Still Matter
https://websitedevelopment.biz/guides/seo-friendly-url-structure
Updated 2026-08-07 · SEO

URLs are a small ranking factor and a large usability and maintenance factor. Their real value is stability: a URL you never have to change is a URL that keeps its links, its rankings and its bookmarks.

This guide covers the rules that still matter, the ones that no longer do, and how to change a URL when you genuinely must.

### The rules worth following
These are consistent across search engines and, more importantly, across the years — they are as much about maintenance as about ranking.
- Lower case only. Some servers treat /Page and /page as different URLs, which creates duplicates by accident.
- Hyphens between words, not underscores or camel case.
- Short and descriptive. If someone reads the URL aloud, they should be able to guess the page.
- No stop words needed: /guides/website-planning beats /guides/how-to-plan-a-website-for-your-business.
- No file extensions on content pages. /about, not /about.php — it hides the implementation and survives a migration.
- One canonical trailing-slash decision, enforced with a redirect.
- ASCII where practical; non-ASCII URLs work but become percent-encoded when copied, which is ugly and error-prone.
The single most valuable property is stability. A slightly imperfect URL that never changes is worth more than an optimised one that changes twice.

### What no longer matters much
Several long-standing beliefs about URLs have limited effect today, and following them can actively hurt.
| Exact-match keyword URLs rank better | Marginal at best; stuffing looks spammy |
| Deep folder structure signals hierarchy | Click depth matters, path depth barely does |
| Dates in URLs help freshness | They make evergreen content look stale |
| Shorter is always better | Descriptive beats terse; /p/4821 helps nobody |
| Subdomain versus subfolder is decisive | Subfolders are simpler to manage; either can work |
| Query strings cannot be indexed | They can, but they multiply duplicates — prefer clean paths |

### Multilingual URL patterns
For a site in several languages, the URL pattern is one of the hardest things to change later, because it interacts with hreflang, canonicals and every redirect you will ever write.
| Subdirectory | site.com/de/guides | Simplest; one domain accumulates all authority |
| Subdomain | de.site.com/guides | Cleaner separation; more setup, split signals |
| Country domain | site.de/guides | Strongest local signal; a separate site to run |
| Parameter | site.com/guides?lang=de | Avoid — weak signals and duplicate risk |
Whichever you choose, decide separately whether the slug itself is translated. Translating slugs helps local relevance; keeping them identical is simpler to maintain. Both are defensible — changing your mind afterwards is not.

### Changing a URL without losing traffic
Sometimes a change is genuinely necessary. The procedure is mechanical, and skipping any step is where the traffic goes.
- Confirm it is worth it. A URL change always costs something; an incremental wording improvement rarely pays it back.
- Map old to new, one to one. Every old URL gets a specific destination, not a category page.
- Implement 301s, not 302s, and verify each one returns a single hop.
- Update internal links to point at the new URL directly. Do not rely on your own redirects.
- Update the sitemap, and leave the redirects in place indefinitely — external links never get updated.
- Watch Search Console coverage and your top-page report for four to six weeks.
- Expect a dip, and investigate only if it is still deepening after a month.

Q: Should I include keywords in URLs?
A: Include the words that describe the page, which usually are the keywords. What you should not do is stuff variants: /website-development-services-cheap-website-development is worse than /website-development-services in every way, including for the humans who see it in search results.

Q: Subdomain or subfolder for a blog?
A: Subfolder, in most cases. site.com/blog is simpler to manage, shares the domain’s accumulated signals, and needs no separate technical setup. Subdomains make sense when the section is genuinely a separate application, has a separate team, or must run on different infrastructure.

Q: How long should I keep old redirects?
A: Indefinitely. They cost almost nothing to keep and external links to your old URLs will never be updated. What you should do is periodically collapse chains created by successive migrations, so every old URL points directly at the current destination in a single hop.

Q: Do URL parameters hurt SEO?
A: They are not harmful in themselves, but they multiply near-duplicate URLs quickly — sorting, filtering and tracking parameters can generate thousands of variants of one page. Use clean paths for anything you want indexed, and canonicalise or noindex the parameter variants.

## Multilingual Website Development: Structure, URLs and Workflow
https://websitedevelopment.biz/guides/multilingual-website-development
Updated 2026-08-07 · CMS

Adding languages to a website is rarely just translation. It changes URL structure, adds a set of reciprocal tags that break silently, and introduces a content workflow where one page becomes twelve pages that can drift apart.

This guide covers the structural decisions, the technical requirements, and the workflow that keeps translations from going stale.

### Decide the URL pattern first
This is the decision that is expensive to reverse, because it touches every URL, every redirect and every hreflang tag on the site.
| Subdirectory | site.com/de/guides | Most sites — simplest, one domain accumulates authority |
| Subdomain | de.site.com/guides | Separate infrastructure or separate teams |
| Country domain | site.de/guides | Strong local commitment, and a separate site to run |
| Parameter | site.com/guides?lang=de | Avoid — weak signals, duplicate risk |
Decide separately whether the slug is translated. Translated slugs help local relevance; identical slugs are simpler to maintain. Either is defensible — changing your mind later is not.

### The technical requirements
Each of these fails silently, which is why multilingual sites so often have no working hreflang despite having the tags.
- Reciprocal hreflang. Every page in a language set lists every other, including itself. One missing reverse reference discards the cluster.
- Consistent codes. The same code in the HTML and in the sitemap. Two codes for one page breaks the set.
- x-default pointing at the language selector or the default version.
- Correct lang and dir attributes on the html element for every version.
- Self-referencing canonical per language — never canonicalise translations to the original.
- No automatic redirection by IP or browser language. It breaks crawling and overrides a deliberate choice; offer a suggestion instead.
- Translated metadata. Titles and descriptions in the target language, not the source.

### A translation workflow that survives
The failure mode is not the first translation, it is the fifth edit to the English page that never reaches the other eleven.
- Model translations as linked versions of one content item, so the system knows they belong together.
- Track which translations are outdated relative to the source, and show it in the editing interface.
- Decide what happens when a translation is missing: fall back to the default, or do not publish that URL at all.
- Never publish a URL that has no translation — a page that half-renders in another language is worse than not existing.
- Keep a review date per language, not per content item.
- Give translators context: a screenshot or a preview beats a spreadsheet of strings.
- Decide who owns each language. Unowned languages go stale first.
Machine translation as a starting point is fine; publishing it unreviewed is not. Unreviewed output reads as unreviewed, and it is exactly the kind of low-value content search engines are increasingly explicit about.

### Beyond text
Translation is the part everyone budgets. These are the parts that get missed and cause visible errors.
| Dates and numbers | Format and separators differ by locale |
| Currency | Symbol, position and rounding conventions |
| Addresses and phone numbers | Field order and validation rules |
| Names | Given and family name order is not universal |
| Text length | German and Finnish run long; layouts must flex |
| Reading direction | Arabic and Hebrew need logical CSS properties |
| Images with text | Need a version per language, or no text in the image |
| Legal pages | Requirements differ by jurisdiction, not only by language |

Q: Should I redirect visitors to their language automatically?
A: No. Automatic redirection based on IP or browser language interferes with crawling — a crawler from one country may never see the other versions — and it overrides deliberate choices, which is infuriating for anyone reading in a second language. Show a dismissible suggestion and let the visitor decide.

Q: Is machine translation acceptable?
A: As a first draft, yes, and it saves real money. Published without human review it produces content that reads as machine-generated, which affects both users and search quality assessment. The pragmatic approach is machine translation plus a native reviewer, especially for pages that sell or explain something important.

Q: What breaks hreflang most often?
A: Non-reciprocal tags: page A lists B, B does not list A, and the whole cluster is ignored. Second is mismatched codes between HTML and sitemap. Both are avoided by generating hreflang from a single source of truth rather than maintaining two lists.

Q: Do I need to translate the whole site?
A: No, and partial translation is normal. Translate what has demand in that market and let the rest exist only in the source language. What you must not do is publish an empty or half-translated URL — either the page exists properly in that language or it does not exist at all.

## Site Speed Optimisation: A Practical Order of Work
https://websitedevelopment.biz/guides/site-speed-optimization-guide
Updated 2026-08-07 · SEO

Site speed work has a strong Pareto shape: a handful of fixes account for most of the improvement on most sites, and they are almost always images, server response and third-party scripts.

This guide covers the order to work in, how to measure whether a change helped, and the optimisations that are usually not worth the effort.

### Measure before you change anything
Optimising without measurement means fixing whatever is easiest rather than whatever is slow. Two measurements, then work.
- Get field data for real visitors — the Core Web Vitals report in Search Console, or your own monitoring.
- Run a lab test on the three most important templates, throttled to a mid-range phone on 4G.
- Record the numbers before you start. Without a baseline you cannot tell whether a change helped.
- Identify the largest single asset and the largest single blocking request on each template.
- Note the Time to First Byte separately: if it is above 800ms, no front-end work will save you.

### The order that pays
Roughly by improvement per hour of effort, for a typical content or brochure site.
| Optimise and correctly size images | Large | Low |
| Remove unused third-party scripts | Large | Low — mostly a political task |
| Enable caching and a CDN | Large | Low |
| Fix render-blocking CSS and JS | Medium to large | Medium |
| Reduce the JavaScript bundle | Medium to large | Medium to high |
| Fix slow database queries | Large where it applies | Medium |
| Optimise font loading | Medium | Low |
| Minify and compress text assets | Small | Low — usually already on |
| Micro-optimise CSS selectors | Negligible | Not worth doing |

### Images: usually the biggest win
On most sites images are the majority of page weight, and most are served at several times the size they are displayed. This is the cheapest large improvement available.
- Serve WebP or AVIF; both are widely supported and typically 25–50% smaller than JPEG at equivalent quality.
- Generate multiple sizes and use srcset with sizes so phones download phone-sized files.
- Never serve a 2000px image into a 400px slot — this single mistake is extremely common.
- Lazy-load everything below the fold, and nothing above it.
- Automate it in the build or the CMS. Hand-optimised images stop being optimised the first time someone else uploads one.
- Strip metadata; camera EXIF can be tens of kilobytes per file.
Automation is the point. A one-off optimisation pass degrades within months as new content is added, and nobody notices until page weight has doubled.

### Third-party scripts and the server
These are the two areas where the problem is usually organisational rather than technical: nobody owns the tag manager, and nobody owns the hosting decision.
| Tag manager with unknown tags | Audit every tag; delete anything nobody can justify |
| Chat widget loading on every page | Load on interaction, or only where support is needed |
| Multiple analytics tools | Keep one; each is a full script and a connection |
| A/B testing script blocking render | Move server-side, or accept a flash and load async |
| Slow TTFB on shared hosting | Add full-page caching; upgrade the plan if it persists |
| Uncached database queries | Cache the expensive ones; add indexes for the common ones |
| No CDN | Add one — it is the cheapest global latency fix available |
Third-party scripts are the most reliable source of unexplained slowdowns, because they change without telling you and are outside your deployment process.

Q: What is a good page load time?
A: The useful targets are the Core Web Vitals thresholds rather than a single load number: LCP under 2.5 seconds, and Time to First Byte under 800ms. Total load time is a poor measure because a page can be usable long before every asset finishes, and unusable well before that on a slow device.

Q: Will a faster site increase conversions?
A: Generally yes, and the effect is largest where pages are currently slow and visitors are on mobile networks. The gain from three seconds to two is far larger than from one and a half to one. If your site is already fast, spend the effort on content and clarity instead — the return is better.

Q: Do caching plugins solve everything?
A: They solve one real thing well — repeated server work for the same page — and they can create new problems, particularly with logged-in users, carts and forms. They also do nothing about oversized images or third-party scripts, which are usually the larger issues. Useful, not sufficient.

Q: Is server-side rendering worth it for speed?
A: If your pages currently render only in the browser, yes: server-rendering or static generation removes an entire round trip before content appears, and it helps indexing at the same time. If your pages are already server-rendered HTML, the question does not apply — you already have the benefit.

## Core Web Vitals for Developers: What Actually Moves the Numbers
https://websitedevelopment.biz/guides/core-web-vitals-for-developers
Updated 2026-08-07 · SEO

Core Web Vitals are three field measurements of how a page feels: how long until the main content appears, how much it moves while loading, and how quickly it responds to input. They are a ranking signal, and more importantly they correlate with whether people stay.

This guide covers what each metric measures, the specific causes behind poor scores, and the fixes that move field data rather than only lab scores.

### What the three metrics measure
Each has a threshold for "good" and each has a small number of usual causes. Note that the number that counts for ranking is field data from real visitors, not a lab score from your laptop.
| LCP | Under 2.5s | Time until the largest visible element renders | Unoptimised hero image, slow server, render-blocking CSS |
| CLS | Under 0.1 | How much layout moves during load | Images without dimensions, injected banners, late web fonts |
| INP | Under 200ms | Responsiveness to user interaction | Long JavaScript tasks blocking the main thread |
Lab tools measure one load on one machine. Field data is the 75th percentile of real visits, which includes old phones on poor networks — the visitors most likely to leave.

### Fixing LCP
LCP is almost always an image or a heading blocked behind something else. Work through these in order; the first two fix most sites.
- Identify the actual LCP element in field data. Optimising the wrong image is the most common wasted effort.
- Never lazy-load the LCP image. Give it fetchpriority="high" instead.
- Serve it in a modern format at the size it is displayed, with srcset for smaller screens.
- Preload the font used by the LCP text and use font-display: swap so text is not invisible while waiting.
- Remove render-blocking CSS and JavaScript from the head; inline the critical CSS if the page is small enough.
- Reduce Time to First Byte with caching and a CDN — no front-end work can compensate for a slow server.
- Cut third-party scripts in the critical path. Each one is a DNS lookup, a connection and an unpredictable file.

### Fixing CLS
Layout shift is almost entirely preventable and the fixes are cheap. It is also the metric visitors notice most viscerally — it is what makes people tap the wrong thing.
- Set width and height attributes on every image and video so the browser reserves space.
- Reserve space for ads, embeds and iframes with a fixed aspect ratio container.
- Never insert content above existing content after load — cookie banners belong at the bottom, or overlaid.
- Match the fallback font metrics to the web font, or use size-adjust, so the swap does not reflow the page.
- Avoid animating layout properties. Animate transform and opacity, which do not trigger reflow.
- Give dynamically loaded sections a min-height so they do not expand from zero.

### Fixing INP
INP replaced First Input Delay and is harder, because it measures every interaction across the visit rather than only the first. Poor INP is nearly always too much JavaScript running on the main thread.
| Large bundle parsed on load | Code-split; load only what the page needs |
| Long tasks over 50ms | Break work into chunks and yield to the main thread |
| Expensive event handlers | Debounce, and move heavy work off the interaction path |
| Heavy third-party tags | Load after interaction, or remove — audit what each one earns |
| Large DOM (10,000+ nodes) | Virtualise long lists; simplify deeply nested markup |
| Layout thrashing in handlers | Batch reads and writes instead of interleaving them |
On content sites the highest-value INP fix is usually deleting JavaScript rather than optimising it. Ask what each script earns; tag managers accumulate scripts nobody remembers adding.

Q: How much do Core Web Vitals affect rankings?
A: They are a real but modest signal, and they act as a tiebreaker rather than as a substitute for relevance. A fast page about the wrong thing does not outrank a slower page that answers the query. The stronger argument for fixing them is behavioural: slow, shifting pages lose visitors before ranking enters into it.

Q: Why is my Lighthouse score good but my field data bad?
A: Because Lighthouse simulates one load on your machine with your connection, and field data is the 75th percentile of real visits — including three-year-old phones on congested mobile networks. When the two disagree, the field data is the one that counts. Use lab tools to diagnose, not to score.

Q: Do I need to fix all three metrics?
A: Fix the ones that are failing, in the order of what your visitors experience. CLS is usually the cheapest to fix and the most annoying to users, so it is a good place to start. LCP has the biggest effect on whether people wait. INP matters most on interactive sites and least on static articles.

Q: How long before improvements show up?
A: Field data is a 28-day rolling window, so meaningful movement takes about four weeks after a fix is deployed to all visitors. Do not judge a change after three days. Do check lab metrics immediately to confirm the fix actually did what you expected.

## CMS Migration: How to Move Without Losing Traffic
https://websitedevelopment.biz/guides/cms-migration-guide
Updated 2026-08-07 · CMS

A CMS migration moves content from one system to another. The risk is not technical — exports and imports are solved problems — it is that structure, URLs and metadata change along the way, and search engines notice all three.

This guide covers the sequence that keeps traffic intact, the audit that should come first, and what to watch afterwards.

### Audit before you move anything
Migrating everything is the default and usually the wrong choice. Most sites carry a substantial tail of pages that get no traffic, have no links and serve no purpose, and moving them imports the problem into the new system.
- Crawl the existing site to get every URL that actually exists.
- Pull twelve months of traffic per URL, plus inbound links.
- Classify each page: migrate as is, rewrite, merge with another, or drop.
- Anything with traffic or links must have a destination. Everything else can go.
- Note which pages carry structured data, custom fields or unusual templates.
- Export the metadata — titles and descriptions — separately. It is the most commonly lost asset in a migration.
Merging thin pages into stronger ones during a migration is one of the few reliably positive SEO outcomes of the whole exercise. Redirect the merged ones to the survivor.

### Model the content before importing it
The temptation is to recreate the old structure exactly. That imports old compromises. Model the content as it should be, then map the old data onto it.
| Content types | What genuinely differs — page, article, product, person, event |
| Fields | Structured fields instead of one HTML blob wherever it is feasible |
| Taxonomies | Which categories and tags survive; most sites have too many |
| Media | Where files live and whether paths change |
| Authors and dates | Preserve real publication dates; do not reset them all to today |
| Metadata | Titles, descriptions and canonicals mapped explicitly |
| Redirect map | Old URL to new URL, one to one, built as you go |
Resetting publication dates on import is a common accident and it destroys the freshness signal on your entire archive at once.

### Preserve URLs, and redirect what you cannot
The single biggest determinant of whether a migration costs traffic.
- Keep the existing URL structure unless it is genuinely broken. "The new CMS prefers a different pattern" is not a good enough reason.
- Where URLs must change, map one to one — never to a category page or the homepage.
- Use 301 redirects, and verify each is a single hop.
- Redirect media files too. Images accumulate links and appear in image search.
- Keep redirects indefinitely; external links are never updated.
- Test the redirect map on staging with the full list before launch, not a sample.

### Launch and the six weeks after
The migration is not finished at cutover. Most problems become visible in the following month.
- Launch when you can watch it. Not Friday, not before a holiday.
- Verify robots.txt, meta robots, canonicals and the sitemap on production immediately.
- Run the full redirect list against production and check for 404s and chains.
- Submit the new sitemap in Search Console and watch coverage daily for a week.
- Compare top pages against the previous period; a page that drops sharply usually has a specific cause.
- Watch server logs for crawler 404s — they find missed URLs faster than analytics does.
- Expect fluctuation for two to six weeks; investigate a decline that is still deepening after a month.
- Keep the old system read-only for a while, so you can check what a page used to contain.

Q: Will I lose search traffic when migrating?
A: Expect a dip of a few weeks even when everything is done correctly — search engines have to recrawl and reassess. With clean redirects and preserved content, traffic normally returns to the previous level within two to six weeks. A permanent loss almost always traces back to missed redirects, changed content, or pages that were quietly dropped.

Q: Should I redesign at the same time?
A: It is tempting and it makes diagnosis much harder: when traffic moves you cannot tell whether it was the migration or the design. If you can separate them, migrate first with the existing templates, confirm stability, then redesign. If they must happen together, be more rigorous about preserving URLs and content.

Q: How do I migrate content that does not map cleanly?
A: Some content always resists automation — custom layouts, embedded widgets, hand-built tables. Identify these during the audit and budget manual time for them. Trying to automate the last 5% usually costs more than doing it by hand, and produces worse results.

Q: Should I keep the old CMS running?
A: Keep it accessible but not public for a few months: read-only, blocked from search engines, on an internal address. It is invaluable for checking what a page used to say when something looks wrong. Then decommission it properly — an abandoned public install is a security liability.

## Technical SEO Checklist for Website Developers
https://websitedevelopment.biz/guides/technical-seo-checklist
Updated 2026-08-07 · SEO

Technical SEO is the part of search work that lives in the codebase rather than in a content calendar. It is largely a checklist, and most of it is verifiable rather than a matter of opinion.

This guide is that checklist, grouped by the problem each item prevents, with the mistakes that are common enough to be worth naming.

### Indexing controls
The purpose here is that exactly the pages you want indexed are indexed, and nothing else — no staging copies, no filter permutations, no printer-friendly duplicates.
- One canonical hostname; every other variant 301s to it — including HTTP and the www/non-www twin.
- Self-referencing canonical on every indexable page.
- noindex, follow on thin or duplicate pages: internal search results, filter combinations, thank-you pages.
- Never block a page in robots.txt that carries a noindex tag — the tag can then never be read, so the URL lingers in the index.
- Staging blocked by HTTP authentication, not only by robots.txt.
- Parameter handling decided: which query strings create a distinct page and which do not.
noindex and a robots.txt block do opposite jobs and cancel each other out. If you want a page gone, allow crawling so the noindex can be seen.

### Redirects and status codes
Redirects are where relaunches quietly lose traffic. The failures are mechanical and easy to test before launch.
| Page moved permanently | 301 to the equivalent page | 302, or redirect to the homepage |
| Page deleted, no equivalent | 410 or 404 | Soft 404: a "not found" page returning 200 |
| Temporarily unavailable | 503 with Retry-After | Returning 200 with an error message |
| Trailing slash variants | One canonical form, other 301s | Both serving the same content at 200 |
| Old domain | 301 mapped page by page | Everything to the new homepage |
| Redirect chains | Collapse to a single hop | A → B → C → D, losing signal at each step |

### Pagination, facets and duplication
Listing pages generate the largest index problems, because a handful of filters can produce thousands of URL combinations that all look like near-duplicates.
- Paginated pages: real crawlable links, each page self-canonical — do not canonicalise page 2 to page 1.
- Filter combinations: noindex, follow by default; index only the small number that match real search demand.
- Sort orders: never create a new indexable URL. Same content, different sequence.
- Session identifiers and tracking parameters: strip them, or canonicalise to the clean URL.
- Printer-friendly and AMP-style duplicates: canonical to the main version.
- Products in multiple categories: one canonical URL, linked from all of them.
Faceted navigation left open is the most common cause of index bloat, and it clears slowly. It is much cheaper to prevent at build time than to unwind afterwards.

### Structured data and international setup
Two areas where a mechanical error silently disables the whole feature.
| Article markup | Only on real articles, with genuine dates | Fake freshness dates get the feature ignored |
| Product markup | Price and availability must match the page | Mismatch triggers a manual action |
| FAQ markup | Only for questions visible on the page | Hidden content is a policy violation |
| Breadcrumbs | Must match the visible trail | Diverging paths are simply ignored |
| hreflang | Reciprocal on every page in the set | One-way tags mean the whole cluster is dropped |
| hreflang codes | Same code in HTML and in the sitemap | Two different codes for the same page breaks the cluster |
| x-default | Points at the language selector or default version | Missing it costs the fallback behaviour |

Q: How do I find technical SEO problems on an existing site?
A: Crawl it with a desktop crawler and compare what you get against your sitemap and against Search Console coverage. The three lists disagreeing is where the problems are: URLs in the crawl but not the sitemap, URLs indexed but not in the crawl, and pages excluded for reasons you did not intend.

Q: Do redirect chains really matter?
A: Yes, for two reasons. Each hop adds latency for real users, and crawlers stop following after a few. After a couple of migrations it is common to find chains four or five deep that nobody planned. Collapse them so every old URL points directly at the final destination.

Q: Should I noindex tag and category pages?
A: Only if they are genuinely thin. A category page with a real description, a curated list and internal links is a legitimate landing page and often a strong one. A tag page with two posts and no text is index bloat. Judge each template on whether it answers a query someone actually has.

Q: What breaks hreflang most often?
A: Non-reciprocal tags. If the English page lists the German alternate but the German page does not list the English one, the cluster is discarded. The second most common failure is declaring one code in the HTML and a different one in the sitemap for the same page. Generate both from the same source so they cannot diverge.

## WordPress vs Webflow vs a Custom Build
https://websitedevelopment.biz/guides/wordpress-vs-webflow-vs-custom
Updated 2026-08-07 · CMS

For a business website, most decisions come down to these three. They are not competitors in a straightforward sense — they suit different teams, different budgets and different appetites for maintenance.

This guide compares them by operating model, three-year cost and exit difficulty, which are the factors that actually decide whether the choice works out.

### The three in one table
The summary, before the detail.
| Model | Self-hosted open source | Hosted visual builder | Your code, your hosting |
| Editing | Good, familiar to many | Excellent visual control | As good as you build it |
| Who maintains it | You | The vendor | You |
| Extensibility | Very large plugin ecosystem | Limited, improving | Unlimited |
| Performance | Depends heavily on the build | Generally good | As good as you pay for |
| Running cost | Hosting plus plugins plus dev time | Subscription per site | Hosting plus dev time |
| Leaving | Full database access | Export is limited and lossy | It is your code |

### Where each one is genuinely strong
Choosing on the strength that matches your situation is more reliable than choosing on the weakness you fear.
- WordPress: content-led sites, blogs, sites that need a specific plugin, teams with WordPress skills, and anything where a large ecosystem saves custom work.
- Webflow: design-led marketing sites where visual control matters and there is no developer to maintain infrastructure. Also good for teams that need to ship landing pages quickly.
- Custom: applications, unusual integrations, strict performance or accessibility targets, or a site that is itself the product.
The most common mismatch is a small team choosing a custom build for a brochure site. It is not wrong technically; it is simply money that would produce more return spent on content.

### Three-year cost, honestly
Rough shape rather than precise numbers, for a mid-sized business site.
| Build | Low to medium | Low to medium | High |
| Hosting | Low to medium | Included in subscription | Low to medium |
| Licences and plugins | Ongoing, rises over time | Included, tiered by usage | Minimal |
| Maintenance | Medium, continuous | Low | Medium |
| Developer time for changes | Low for content, medium for features | Low | Medium |
| Risk cost | Compromise if unpatched | Vendor price and policy changes | Key-person dependency |

### Exit difficulty
How hard it is to leave should be part of the decision, because it determines whether the choice is reversible.
- Custom: easiest in principle — you have the code, the database and the hosting. The risk is documentation and whether anyone else can work with it.
- WordPress: straightforward. Content exports cleanly; the work is rebuilding what plugins were doing.
- Webflow: hardest. You can export static HTML and CSS, but CMS content, forms and interactions do not come with it, so leaving is a rebuild.
Ask the exit question during selection, not during a dispute. It is the cheapest question to ask and the most expensive to have skipped.

Q: Which is best for SEO?
A: All three can be excellent, and all three can be poor. What matters is server-rendered HTML, control over titles and canonicals, clean URLs, sitemaps, structured data and speed. WordPress gives you plugins for this, Webflow has it built in with some limits, custom gives you full control and full responsibility. The build quality dominates the platform choice.

Q: Is WordPress insecure?
A: WordPress core is actively maintained and reasonably secure. Most compromises come from outdated plugins, abandoned themes and weak admin credentials. A patched WordPress with few plugins and two-factor authentication is fine; a site with forty plugins nobody updates is not, and that is a maintenance choice rather than a platform property.

Q: Can Webflow handle a large site?
A: It handles moderate content sites well and has limits on CMS item counts and collection structure that are worth checking against your actual content model before committing. For a large, complex catalogue or heavy custom logic, it is usually the wrong tool — not because it is weak, but because it is not aimed at that.

Q: When is a custom build worth it?
A: When the site does something specific to your business that off-the-shelf tools fight: a configurator, an unusual booking flow, deep integration with your operational systems, or strict performance and accessibility requirements. Distinctive design alone is rarely a sufficient reason, because a custom theme on a CMS achieves that for much less.

## Website Development SEO Basics: What to Build In
https://websitedevelopment.biz/guides/website-development-seo-basics
Updated 2026-08-07 · SEO

A large share of SEO is not marketing at all — it is decisions made during website development that are cheap at build time and expensive later. URL structure, rendering strategy, internal linking and editable metadata all fall into that category.

This guide covers what to build in from the start, in rough order of how painful it is to add afterwards.

### Make sure the site can be crawled and indexed
Everything else is irrelevant if search engines cannot reach or read your pages. This is also where launch-day mistakes cluster.
- robots.txt on production allows crawling. The staging copy must not be deployed with it.
- No stray noindex meta tags carried over from staging.
- Every page has a self-referencing canonical URL, and there is one canonical hostname.
- Content is in the HTML, or server-rendered. If it only appears after JavaScript runs, indexing becomes slower and less reliable.
- An XML sitemap listing only indexable, canonical URLs — not filtered or paginated variants.
- Every indexable page has at least one internal link. Orphaned pages are barely crawled.
- Consistent status codes: 200 for real pages, 404 for missing ones, 301 for moved ones.
The single most common launch failure in this list is the staging robots.txt reaching production. Check it from outside your network on launch day.

### Structure that search engines can read
Structural decisions are the ones that are painful to change later, because changing them means redirects and losing accumulated signals.
| URL pattern | Short, lower case, hyphenated, stable | High — redirects and lost signals |
| Heading hierarchy | One H1, no skipped levels | Low |
| Internal linking | Hubs linking to detail pages and back | Medium |
| Pagination | Crawlable links, not JavaScript-only | Medium |
| Faceted navigation | noindex on filter combinations | High — index bloat is slow to clear |
| Language versions | Prefix URLs plus reciprocal hreflang | Very high |

### Metadata your team can actually edit
A common build failure is generating titles and descriptions from a template with no way to override them. Six months later marketing needs to change one page's title and the answer is a developer ticket.
- Editable title tag per page, with a sensible generated default.
- Editable meta description, with a visible character counter in the CMS.
- Editable Open Graph title, description and image for shared links.
- Structured data on the templates that support it: Article, Product, FAQ, Breadcrumb, Organization.
- A per-page noindex switch for pages that should exist but not rank.
- Automatic canonical, with a manual override for the rare case that needs one.
Only mark up what is actually visible on the page. Structured data describing content a visitor cannot see is a policy violation, not a shortcut.

### Speed and stability as build requirements
Page experience is part of the build, not a later optimisation project. Retrofitting speed onto a finished site usually means undoing decisions rather than adding code.
| Largest Contentful Paint | Under 2.5s | Prioritising the hero image, avoiding render-blocking assets |
| Cumulative Layout Shift | Under 0.1 | Width and height on images, reserved space for embeds |
| Interaction to Next Paint | Under 200ms | Less JavaScript, and not blocking the main thread |
| Page weight | As low as the design allows | Modern image formats, no unused libraries |
| Time to First Byte | Under 800ms | Caching, a CDN, and sensible database queries |

Q: Should SEO be in the development brief?
A: The technical parts, yes — crawlability, URL structure, editable metadata, structured data, performance targets and redirect mapping. Content strategy and link building are separate work with a different skill set. Putting the technical requirements in the brief means they are quoted rather than discovered after launch, which is when they cost several times more.

Q: Does a JavaScript framework hurt SEO?
A: It can, if pages are rendered only in the browser. Search engines can execute JavaScript but do so on a delay and not always completely, so client-only rendering makes indexing slower and less reliable. Server-side rendering or static generation removes the problem. For a content site the simplest answer is usually to put the content in the HTML.

Q: How long after launch before I see search traffic?
A: For a brand-new domain, typically weeks for indexing and months before meaningful rankings — new sites do not rank quickly regardless of technical quality. For a relaunch of an existing site with clean redirects, expect two to six weeks of fluctuation before things settle back around the previous level.

Q: Do I need an SEO plugin?
A: On a CMS, a plugin is a convenient way to give editors control over titles, descriptions, canonicals and sitemaps. It is not a strategy, and its default output is not a substitute for someone deciding what each page should be about. On a custom build the same functionality is usually written directly and is lighter for it.

## Headless CMS vs Traditional CMS: Which Fits Your Site?
https://websitedevelopment.biz/guides/headless-cms-vs-traditional-cms
Updated 2026-08-07 · CMS

A traditional CMS stores content and renders the pages. A headless CMS stores content and hands it over through an API, leaving rendering entirely to you. That single difference cascades into everything: preview, cost, team structure and how quickly a marketer can change a page.

This guide covers what you gain, what you lose, and where the middle ground sits.

### The actual difference
Everything else follows from where rendering happens.
| Rendering | The CMS produces the HTML | Your front-end does |
| Templates | Inside the CMS | In your codebase |
| Preview | Built in and accurate | You have to build it |
| Channels | One website | Website, app, kiosk, anything that can call an API |
| Front-end freedom | Bounded by the CMS | Complete |
| Time to first page | Fast | Slow — nothing renders until you build it |
| Who is needed for a layout change | Often an editor | A developer |

### What you give up going headless
The features a traditional CMS provides for free are the ones people miss, and they are usually discovered after the decision is made.
- Preview. Editors expect to see the page before publishing. In headless this is a feature you build and maintain.
- Page composition. Arranging blocks on a page is a solved problem in traditional systems and a build in headless ones.
- Menus and navigation. Also something you now model and build yourself.
- Forms. No form builder comes with the API.
- Redirects and URL management. Yours to implement.
- Plugin ecosystem. SEO fields, sitemaps, redirects — all of it becomes custom work.
- Speed of small changes. "Move that section up" stops being an editor task.
The recurring pattern in disappointing headless projects is a marketing team that could previously change a page themselves and now files tickets.

### When headless is the right call
It fits a specific shape of problem, and outside that shape it is expensive flexibility.
| Content shown in a site and a mobile app | Strong — this is the core case |
| Several sites sharing one content source | Strong |
| Front-end requirements the CMS cannot meet | Strong |
| A dedicated front-end team already exists | Good |
| Marketing site with a small team | Poor — you lose speed and gain tickets |
| Content-led site with frequent layout changes | Poor |
| "It is the modern approach" | Not a reason |

### The middle ground
Most sites are better served by something between the two extremes.
- Traditional CMS with a custom theme. Full front-end control, and preview and composition still work.
- Traditional CMS used headlessly for one surface. The website stays rendered by the CMS; the app consumes an API.
- Headless CMS with a static site generator. Editors get a good interface, the site is static and fast; preview needs work.
- Hybrid CMS. Systems that offer both rendered pages and an API — often the pragmatic answer.
- Static generator with a git-based editor. Very low cost and very low risk for content that is mostly documents.
A custom theme on a traditional CMS gives you most of the front-end freedom people go headless for, without giving up preview, composition and the ecosystem.

Q: Is headless better for performance?
A: It can be, because you control exactly what is sent — but the gain comes from static generation and a lean front-end, not from the API. A well-built traditional CMS with proper caching and a custom theme is fast too. Performance is a consequence of how you build, not of where the content is stored.

Q: Is headless better for SEO?
A: Neutral at best, and worse if pages render only in the browser. Everything technical SEO needs — server-rendered HTML, canonicals, sitemaps, structured data, redirects — has to be implemented yourself in headless, whereas traditional systems have mature plugins for it. Headless is fine for SEO with discipline and disappointing without it.

Q: Can editors preview content in a headless setup?
A: Yes, but you build it: a preview mode in the front-end that fetches draft content and renders it. Budget for it explicitly. Projects that skip preview end up with editors publishing to production to see how something looks, which is exactly what a CMS is supposed to prevent.

Q: What does headless cost compared with traditional?
A: The initial build is typically higher, because you are building the front-end plus the features a traditional CMS included. Running costs can be lower, especially with static generation. The bigger long-term difference is that more routine changes require developer time, which is a continuing cost that does not show up in the build quote.

## Do You Need a Design System for Your Website?
https://websitedevelopment.biz/guides/design-system-for-websites
Updated 2026-08-07 · Web design

A design system is a set of reusable components and the rules for using them. On a large site with several people making changes it removes a great deal of duplicated decision-making. On a five-page brochure site it is a cost with no return.

This guide covers where the line is, what a minimum useful system actually contains, and what to do instead when a full system is not justified.

### When it pays and when it does not
The value comes from repetition: the same decision made once instead of forty times, and consistently. If the repetition is not there, neither is the value.
| Five-page brochure site, one designer, rare changes | No — a style guide page is enough |
| One site, several templates, occasional content changes | Light: tokens and a component sheet |
| Site plus app sharing a brand | Yes — the shared surface is where drift happens |
| Several sites in one organisation | Yes — this is the strongest case |
| Frequent A/B testing and campaign pages | Yes — speed of assembly is the payoff |
| Rebuild planned within a year | Not yet — build the system with the rebuild |

### The minimum useful system
Most of the benefit comes from a small core. You can build this in days, not months, and it is enough for most websites that need one at all.
- Tokens: colour, type scale, spacing scale, radii, shadows, breakpoints — named, not hard-coded numbers.
- Typography: heading levels and body styles with their responsive behaviour.
- Buttons and links: every state — default, hover, focus, active, disabled, loading.
- Form controls: input, select, textarea, checkbox, radio, plus error and hint styles.
- Cards and lists: the two or three repeating content containers your site actually uses.
- Navigation: header, footer, breadcrumb, pagination.
- Feedback: empty state, error state, loading state, success message.
States are the part that gets skipped and the part that matters most. A component defined only in its default state hands every edge case back to whoever is implementing it.

### The maintenance cost nobody budgets
A design system is a product with users, and it needs an owner. Without one it drifts: the site gains components the system does not have, the system keeps components nothing uses, and after a year people work around it rather than with it.
- Someone owns it and decides what goes in. A system owned by a committee stops changing.
- A documented route for proposing a new component, so people extend it rather than bypass it.
- Versioning, so a change does not silently alter every page at once.
- A periodic audit of what is in the live site but not in the system — that gap is the health measure.
- Deletion. Unused components are cost, not value.

### Lighter alternatives
If the case for a full system is not there, there are cheaper steps that capture much of the consistency benefit.
| CSS custom properties for colour, type and spacing | Hours | Any site at all — this is the floor |
| A single live style guide page in the site itself | A day | Small sites with occasional contributors |
| Component library in the CMS or template layer | Days | Content teams assembling pages |
| Established CSS framework, lightly themed | Days | Internal tools and admin screens |
| Full documented design system | Weeks to months | Multiple products or multiple teams |
A live style guide page inside the real site beats a document: it uses the same CSS, so it cannot drift from reality without visibly breaking.

Q: Can I use an off-the-shelf design system?
A: Yes, and for internal tools it is usually the right call — the branding matters little and you get accessible, tested components immediately. For a public marketing site the trade is that your site looks like every other site using the same system, so most organisations theme it heavily, at which point some of the maintenance saving disappears.

Q: Who should own the design system?
A: One named person, with input from designers and developers. Shared ownership between design and engineering sounds collaborative and in practice means nobody decides, so the system stops evolving and people route around it. The owner does not have to build everything; they have to say yes and no.

Q: What is the difference between a style guide and a design system?
A: A style guide documents appearance: colours, typefaces, logo usage. A design system includes that plus working components, their states, the rules for combining them, and usually the code. A style guide tells you what things look like; a design system gives you the parts and tells you when to use each one.

Q: How do I stop it going stale?
A: Make it the path of least resistance and audit the gap. If using the system is slower than writing one-off CSS, people will write one-off CSS. Periodically list the components in the live site that are not in the system: a growing list means the system is not serving the people building pages, and that is a design problem in the system itself.

## How to Become a Website Developer: A Realistic Path
https://websitedevelopment.biz/guides/how-to-become-a-website-developer
Updated 2026-08-07 · Hiring developers

Becoming a website developer is a matter of learning a specific, finite set of things and then proving you can finish work. The learning is well documented and free; the harder part is building evidence that someone should pay you.

This guide covers a realistic order of learning, honest timescales, what a portfolio actually needs, and how first clients are found.

### What to learn, in order
Order matters more than pace. Each layer makes the next one comprehensible, and skipping ahead produces developers who can copy solutions but not diagnose problems.
- HTML, properly. Semantics, forms, accessibility. Most professional developers have gaps here and it shows in their work.
- CSS, properly. The box model, flexbox, grid, custom properties, responsive layout. This is where a beginner can become genuinely useful quickest.
- JavaScript fundamentals. The language itself and the DOM, before any framework.
- Version control. Git, branches, pull requests. Non-negotiable for working with anyone.
- How the web works. HTTP, status codes, caching, DNS, TLS. This is what separates diagnosis from guessing.
- A back-end language and SQL. Any one of the common choices; the concepts transfer.
- A CMS or a framework, chosen for what work exists near you.
- Deployment. Getting a site onto real hosting, with a domain and a certificate.
Depth in HTML and CSS is undervalued and immediately marketable. A developer who can build fast, accessible, responsive interfaces is more employable than one who knows three frameworks shallowly.

### How long it actually takes
With consistent study of 15–20 hours a week. Full-time compresses this, and nothing compresses the last row.
| Basics of HTML and CSS | 1–2 months | Build a static page from a design |
| Responsive layout and JavaScript basics | 3–5 months | Build a small site with interaction |
| First real project | 5–8 months | Ship something for someone else |
| Employable junior | 8–14 months | Contribute to a codebase with supervision |
| Working independently | 2–3 years | Run a small project end to end |
| Senior | 5+ years | Make architectural decisions and be right often |
The step people underestimate is "ship something for someone else". Building for yourself teaches syntax; building for a client teaches scope, feedback, deadlines and the fact that requirements change.

### What a portfolio needs to show
Three or four finished, live, well-explained projects beat twenty tutorial clones. What is being judged is whether you finish things and whether you understand what you built.
- Live URLs, not screenshots. It must work when someone clicks.
- A short write-up per project: the problem, your decisions, what you would do differently.
- At least one real project with a real user, even unpaid — a local business, a club, a charity.
- Evidence of quality: fast, accessible, works on a phone. People will check.
- Your own site, done well. It is the first thing anyone looks at and the easiest thing to get right.
- Code on a public repository with readable commits and a README that explains how to run it.

### Finding the first clients
The first two or three are the difficult ones. After that, most work comes from referral, which means finishing well matters more than marketing.
- Start with people you already know. Almost every developer’s first paid work came this way.
- Pick a niche rather than being general. "Websites for dental practices" is far easier to sell than "websites".
- Solve one specific expensive problem — site speed, an accessibility audit, a migration — rather than offering everything.
- Charge from the first project, even a small amount. Free work is valued accordingly and attracts unlimited scope.
- Write down scope and payment terms before starting, however small the job.
- Finish properly: handover, documentation, an offer of maintenance. This is what produces the second client.
- Ask for a referral when the client is happiest, which is right after launch.

Q: Do I need a computer science degree?
A: No, and a large share of working web developers do not have one. A degree helps in some large organisations and for roles closer to computer science than to web development. For most website work, evidence of finished projects matters more than credentials — but you do need the fundamentals that a degree would have given you, learned some other way.

Q: Front-end or back-end first?
A: Front-end, in almost every case. You see results immediately, which sustains motivation, and it is the shortest path to being useful to someone. Once you can build interfaces properly, back-end concepts are easier to learn because you already understand what the data is for.

Q: Is it too late to start?
A: No, and career changers frequently do well because they bring domain knowledge someone else lacks — accountants who build for accountants, teachers who build for schools. The market for junior generalists is competitive; the market for someone who understands a specific industry and can build is much less so.

Q: Should I learn a framework early?
A: Learn the fundamentals first. Frameworks change every few years and are much easier to pick up when you understand what they are abstracting. Developers who learned a framework without the underlying language tend to be effective inside its patterns and stuck outside them, and that ceiling arrives quickly.

## What Is a CMS and Do You Actually Need One?
https://websitedevelopment.biz/guides/what-is-a-cms
Updated 2026-08-07 · CMS

A content management system lets people who do not write code create and change pages. That is the whole value proposition, and it is a real one — but it is not free, because a CMS is software that has to be hosted, updated and secured for as long as the site exists.

This guide covers what a CMS actually gives you, when it is worth the overhead, and what to use when it is not.

### What a CMS provides
Beyond "edit pages", these are the capabilities you are buying — and they are worth listing because most CMS decisions are made without checking which of them you need.
- Editing without deployment. Change text and publish immediately.
- Structured content. Fields rather than a blob of HTML, so content can be reused and rendered consistently.
- Media management. Upload once, use anywhere, with automatic resizing.
- Users and permissions. Authors, editors, approvers with different rights.
- Workflow. Drafts, previews, scheduling, revision history.
- Search and navigation generated automatically from content.
- Extensibility. Forms, commerce, translations through an ecosystem.
If you only need the first item on this list and one person makes changes twice a year, a CMS is a large amount of machinery for a small job.

### The overhead nobody mentions at the start
A CMS is a running application, which means it has an ongoing cost profile whether or not anyone edits the site.
| Security patching | Popular systems are constantly probed; updates are not optional |
| Plugin maintenance | Every extension is another update and another possible breach |
| Hosting | A database-backed application needs more than static files |
| Performance work | Dynamic pages need caching to be fast |
| Version upgrades | Major versions can break themes and customisations |
| Training | Editors need to know how to use it without breaking layouts |

### When you need one, and when you do not
The deciding factor is change frequency multiplied by the number of people who need to make changes.
| Marketing team publishing weekly | Yes — this is exactly the case a CMS is for |
| Five-page site changed twice a year | No — a static site is cheaper and safer |
| Documentation maintained by developers | No — files in version control work better |
| Online store | Yes, and a commerce platform rather than a general CMS |
| Landing pages for campaigns | Yes — speed of publishing is the whole point |
| Site with several content types and translations | Yes — structure is what a CMS is good at |

### The alternatives
For sites that change rarely, there are options with much lower running costs and almost no attack surface.
- Static site generator. Content in files, built to HTML, deployed to a CDN. Fast, cheap and almost nothing to attack — but editing needs a technical workflow unless you add an editing layer.
- Static generator plus a git-based editor. Non-technical editing on top of files, keeping the static output.
- Headless CMS plus static generation. Editors get a friendly interface; the public site is still static.
- Hand-built HTML. Perfectly reasonable for a small brochure site that genuinely never changes.
- Website builder. The editing is the product; the trade is portability and performance.
The static route removes an entire category of risk: there is no database to inject into and no admin login to brute-force. For a site that changes monthly, that is a meaningful saving.

Q: Is WordPress the default choice?
A: It is the most common one, and commonality brings a large ecosystem, plenty of people who know it, and a correspondingly large amount of automated attention from attackers. It suits content-led sites well. It is not automatically right for applications, complex commerce, or sites whose content is mostly structured data rather than pages.

Q: What is the difference between a CMS and a website builder?
A: A CMS manages content and usually leaves the presentation to templates you or a developer control. A builder combines content and layout in one visual editing tool. Builders are quicker for non-technical users and harder to leave, because layout decisions live inside the product rather than in code you own.

Q: Can I add a CMS to an existing static site?
A: Yes, and it is a common upgrade path — either a headless CMS supplying content to the existing templates, or a git-based editing layer over the current files. It is usually less work than a full migration, because the templates and the URLs stay where they are.

Q: How many plugins are too many?
A: There is no fixed number, but every plugin is an update to apply, a possible conflict and a possible vulnerability. A useful discipline is to justify each one against what it earns: if it saves an hour a year and needs quarterly attention, it is costing you. Sites with forty plugins are almost always carrying several nobody can explain.

## Questions to Ask a Web Developer Before You Hire
https://websitedevelopment.biz/guides/questions-to-ask-a-web-developer
Updated 2026-08-07 · Hiring developers

Most questions asked in a first call are about technology, and technology is the part that matters least to whether the project succeeds. The questions that predict outcomes are about process, ownership and what happens when something goes wrong.

This guide lists those questions, grouped by what they reveal, with a note on what a good answer sounds like.

### About the work itself
These establish whether they have understood your project or are describing their standard offering.
| What questions do you have about our business? | Any at all. Silence here is the strongest negative signal there is |
| Show me a live site at our scale | A URL, not an image; ideally not their showcase piece |
| What would you do differently from our current site? | Specific observations, meaning they looked |
| What is the riskiest part of this project? | An honest answer — usually content or integrations |
| What is not included in this quote? | A specific list offered readily |
| How long, and what drives that? | A schedule with dependencies, not a single number |

### About process
These separate developers who have a repeatable way of working from those who improvise.
- Where is the code stored, and will we have access from day one?
- How does a change get from your machine to the live site?
- Where do we review work before it goes live?
- How often will we see progress, and in what form?
- Who exactly will do the work, and what happens if they are unavailable?
- How do you test — browsers, devices, accessibility, performance?
- What do you need from us, and by when?
The deployment question is the single most revealing one. An answer involving dragging files into an FTP client tells you there is no version control, no staging and no rollback.

### About what happens afterwards
The period nobody asks about during the pitch and everybody cares about six months later.
- Who owns the code, the domain and the hosting accounts after launch?
- What support is included after launch, for how long, and what counts as a defect?
- What does a small change cost afterwards, and what is the turnaround?
- Do you offer maintenance, what is in it, and do we receive a report?
- If we stop working together, what do we receive and how quickly?
- Can another developer take this over? What documentation exists?
- What third-party services will the site depend on, and who pays for them?

### Answers that should end the conversation
Rare, but worth recognising immediately.
| "We guarantee first-page rankings" | Nobody can; it is either ignorance or dishonesty |
| "We keep the domain in our account" | It makes you a hostage |
| "You do not need staging, we are careful" | Everyone is careful; that is not a process |
| "We do not use version control for small sites" | No history, no rollback, no second developer |
| "The price is only valid if you sign today" | Pressure tactics predict the working relationship |
| "SEO is included" with no detail | Either meaningless or a separate service being implied |
| "We will figure out the details as we go" | On a fixed price, this becomes your problem |

Q: What is the single most useful question?
A: "How does a change get from your machine to the live site?" It is answerable in one sentence by anyone competent, and the answer reveals whether version control, staging, review and rollback exist. Everything else on the process list tends to follow from it in one direction or the other.

Q: Should I ask about specific technologies?
A: Only where you have a genuine constraint — an existing system, a platform your team already runs. Otherwise the technology is their decision and asking about it invites an answer designed to impress. Ask what outcomes it produces: how fast, how maintainable, who else could work on it.

Q: How do I check a reference properly?
A: Ask about a problem rather than about satisfaction: "what went wrong, and how did they handle it?" Every project has something. A reference who cannot name anything either had a trivial project or is not being candid. Also ask whether they would use them again for a bigger project, which is a sharper question than whether they were happy.

Q: Is it rude to ask about ownership and termination?
A: No, and a professional supplier expects it. Both parties benefit from knowing where they stand, and the answers are short. Discomfort with these questions is itself information — it usually means the standard arrangement is less favourable to you than it should be.

## Website Accessibility: What to Fix First
https://websitedevelopment.biz/guides/website-accessibility-guide
Updated 2026-08-07 · Web design

Accessibility work has a long checklist and a short list of things that account for most of the actual barriers. Starting with the short list gets real users onto your site quickly; starting with a full audit usually produces a document nobody actions.

This guide covers what to fix first, how to test it yourself in an afternoon, and why overlay widgets are not the shortcut they are sold as.

### The fixes with the largest effect
These are the barriers that stop people completing tasks entirely, rather than making them slightly harder. Fix them before anything on a longer list.
- Keyboard access. Every interactive element reachable with Tab and operable with Enter or Space, in a sensible order, with a visible focus ring. If you can only use the site with a mouse, nothing else on this list matters.
- Text alternatives. Meaningful alt text on images that carry information; empty alt on decorative ones. A missing alt is not the same as an empty one.
- Form labels. A real <label> connected to every input. Placeholder text is not a label — it disappears on typing and is not announced reliably.
- Contrast. Body text at 4.5:1, large text and controls at 3:1, checked against the real background.
- Headings. One H1, no skipped levels. Screen reader users navigate by heading more than by anything else.
- Link text. "Read more" repeated fourteen times gives a screen reader user fourteen identical destinations. Say where it goes.
- Error messages. Next to the field, in text, describing what to do — not colour alone, not a red border alone.

### Test it yourself in an afternoon
You do not need specialist software to find most problems. These five passes take an hour or two on a medium site and find the majority of real barriers.
| Keyboard only | Unplug the mouse, Tab through every page | Traps, invisible focus, unreachable controls |
| Zoom to 200% | Browser text size, not page zoom | Clipped text, horizontal scroll, broken layouts |
| Screen reader | VoiceOver or NVDA on the main templates | Missing labels, meaningless links, unannounced changes |
| Automated scan | axe or Lighthouse in the browser | Contrast, missing alt, ARIA misuse — about 30% of issues |
| Greyscale | Browser filter or OS setting | Anything conveyed by colour alone |
Automated tools find roughly a third of accessibility issues. They are a starting point, not a pass mark — a site that scores 100 in Lighthouse can still be unusable with a keyboard.

### The patterns that cause the most trouble
Custom components are where accessibility usually breaks, because native elements come with behaviour that custom ones have to reimplement.
- Custom dropdowns built from divs, without keyboard support or roles. A native <select> is free and works everywhere.
- Modals that do not trap focus, do not close on Escape, and leave the background scrollable.
- Carousels that auto-advance with no pause control — they are hostile to nearly everyone, not only to disabled users.
- Icon-only buttons with no accessible name. An X with no label is announced as "button".
- Infinite scroll with no way to reach the footer.
- Div soup: clickable divs instead of buttons and links, which removes keyboard support and semantics in one move.
- Motion that ignores prefers-reduced-motion.
The cheapest accessibility strategy is using the native HTML element for the job. Every custom replacement is a promise to reimplement behaviour that came free.

### Why overlay widgets are not a solution
Accessibility overlays promise compliance from a single script. They cannot deliver it, because the underlying problems are structural: a script cannot know what an image depicts, cannot write a form label that matches the field's purpose, and cannot repair a keyboard trap in a custom component.

They also interfere with the assistive technology people already use and have configured, which is why a number of disability organisations advise against them. They are worth knowing about mainly so you can decline them for a defensible reason.
- They cannot generate accurate alt text, because they do not know what the image means in context.
- They cannot fix keyboard traps in components they did not build.
- They frequently conflict with the user’s own screen reader settings.
- They do not remove legal exposure — the underlying barriers are still there.
- The money is better spent on the seven fixes at the top of this page.

Q: Is accessibility legally required?
A: In many jurisdictions, yes, for public bodies and increasingly for private businesses — the European Accessibility Act, the ADA in the United States as applied to websites, and equivalents elsewhere. The obligations differ by country and by sector, so check locally. The practical position is that WCAG 2.2 AA is the standard nearly every regulation points at.

Q: How much does accessibility add to a build?
A: Designed in from the start, very little — mostly discipline about semantics, contrast and focus states. Retrofitted onto a finished custom site it can be a significant project, because the fixes are structural rather than cosmetic. That difference is the whole argument for raising it in the brief rather than after launch.

Q: What is the difference between WCAG A, AA and AAA?
A: They are conformance levels. A is the minimum and leaves real barriers in place; AA is what regulations generally require and what most organisations target; AAA includes criteria that are not achievable for all content — for example a 7:1 contrast requirement that some brand palettes cannot meet. Aim for AA and treat AAA as a per-criterion improvement rather than a target.

Q: Does accessibility help SEO?
A: Indirectly and genuinely. Proper heading structure, descriptive link text, alt attributes, real semantics and fast, stable pages all help both. But the overlap is partial: a site can rank well and still be unusable with a keyboard. Do accessibility work because people cannot use the site otherwise, and take the SEO benefit as a side effect.

## Website Development Contract: What to Check Before Signing
https://websitedevelopment.biz/guides/website-development-contract-checklist
Updated 2026-08-07 · Hiring developers

A website development contract matters on exactly two occasions: when the project goes badly, and when the relationship ends. Both are foreseeable, and a handful of clauses determine how much they cost you.

This guide covers what to check before signing, what each clause is protecting you from, and the terms worth negotiating.

### Ownership: the clause that cannot be fixed later
Everything else in a contract can be renegotiated. Ownership cannot, once the relationship has ended badly.
- You own the source code on final payment, with no ongoing licence condition.
- The domain is registered to your organisation, with your billing details — not the developer’s.
- Hosting and third-party accounts are in your name, with the developer added as a user.
- Content, images and copy you supplied remain yours; ask about anything they create.
- Third-party licences — fonts, plugins, stock images — are transferred or listed so you can buy your own.
- If any code is licensed rather than owned, that is stated explicitly with its terms.
- On termination you receive the code, the database and the credentials within a stated period.
"You own the code once the final invoice is paid" is the sentence to look for. "We grant you a licence to use the site" is a different arrangement and you should know you are choosing it.

### Scope, changes and revisions
Most disputes are scope disputes wearing another name. These clauses decide who pays for the disagreement.
| Scope of work | A specific list, attached as a schedule, not a paragraph |
| Out of scope | An explicit exclusions list — content, photography, entry, SEO |
| Change process | Who requests, who prices, how it is approved, effect on the date |
| Revision rounds | A number, and the cost of a further round |
| Acceptance | What counts as approval, and how long you have to review |
| Client obligations | What you must supply, by when, and the effect if it is late |
| Delay | What happens on both sides — this should not be one-directional |

### Payment, launch and support
Payment tied to things you can see protects both parties; it is not an adversarial request.
- Milestone payments against deliverables you can inspect, not against dates alone.
- A deposit of 30–50% is normal; full payment before work starts is not.
- Final payment on launch, not on an internal sign-off you cannot verify.
- A defined post-launch period for fixing defects — commonly 30 to 90 days — and what a defect means.
- The difference between a defect (they fix it) and a new request (you pay) stated with examples.
- Response times by severity, if the site being down matters to your business.
- Whether maintenance is included, optional or absent — and its price if you take it later.

### Termination and the things people forget
The clauses that only matter once, and matter a great deal then.
| Notice period | Both sides should be able to exit with reasonable notice |
| Payment on termination | What is owed for work completed but not delivered |
| Handover | Code, database, credentials and documentation, within a stated period |
| Liability cap | Usually the contract value; know what it is |
| Data protection | Required if they process personal data on your behalf |
| Confidentiality | Mutual, and it should survive termination |
| Portfolio rights | They will want to show the work; agree the terms now |
| Governing law | Matters a lot with an overseas supplier |
| Dispute process | Mediation before litigation saves money on both sides |
A supplier who is comfortable with a clear termination clause is usually a supplier who expects the relationship to go well. Resistance to it is worth asking about.

Q: Do I need a lawyer for a website contract?
A: For a small project, a clear written agreement covering the points above is usually proportionate. For anything substantial — a store, an application, or a build that would seriously hurt to lose — a couple of hours of legal review is cheap against the value at risk. At minimum, have someone who is not enthusiastic about the project read it.

Q: Is it normal for the developer to hold the domain?
A: It is common and it is not in your interest. The domain should be registered to your organisation with your billing details; add the developer as a technical contact if they need access. Domains held by a former supplier are one of the most reliably painful situations in this industry.

Q: What is a reasonable deposit?
A: Thirty to fifty per cent, with the balance across milestones and launch. A deposit is legitimate — it covers the supplier’s risk of you disappearing. Full payment in advance moves all the risk to you, and offers no leverage if the work stalls at eighty per cent.

Q: What if the project runs late?
A: The contract should address delay on both sides, because it is very often caused by content or decisions from the client. Look for a clause that distinguishes them and states the consequence. Penalty clauses sound reassuring and usually just raise the price, since the supplier prices the risk in.

## Website Launch Checklist: What to Check Before You Go Live
https://websitedevelopment.biz/guides/website-launch-checklist
Updated 2026-08-07 · Website planning

Launch day problems are almost never exotic. They are a staging site left open to search engines, a contact form that goes to an address nobody reads, and an old URL structure with no redirects.

This checklist covers what to verify before you go live, in the order a launch actually happens, and what to watch in the first hour and the first week.

### Before launch: technical
These are the checks that are hard to notice from the outside and expensive to discover late.
- HTTPS works on every page, and HTTP redirects to it with a 301.
- One canonical hostname: www or non-www, with the other redirecting. Not both serving content.
- The staging site is password-protected or blocked, and its noindex has NOT been copied to production.
- robots.txt on production allows crawling. This is the single most common launch mistake.
- A 404 page exists, returns an actual 404 status, and offers a way onward.
- Forms submit, store the record, and send notifications to an address someone reads.
- Backups are configured and one restore has been tested. Untested backups are not backups.
- Error logging is on and someone receives the alerts.
Check the response status codes, not just the pages. A "404 page" that returns HTTP 200 tells search engines every mistyped URL is a real page.

### Before launch: content and SEO
Content checks are quick but they are the ones visitors notice first, and the SEO checks are the ones that are painful to fix after the fact.
- Every page has a unique title and meta description that reflect what is on it.
- No placeholder text, no "Lorem ipsum", no "[client name]" left anywhere.
- Every image has meaningful alt text — decorative images get an empty alt, not a missing one.
- Heading structure is sane: one H1 per page, no jumps from H1 to H4.
- Internal links all resolve; no links to the staging domain.
- XML sitemap generates, lists only indexable URLs, and is referenced in robots.txt.
- Redirects from every old URL with traffic or links, mapped and tested.
- Structured data validates on the templates that carry it.
- Open Graph tags produce a sensible preview when the URL is pasted into a chat app.

### Before launch: legal, analytics and accessibility
The parts most often left to "after launch", which then means never.
| Privacy policy | Present, accurate about what you actually collect, linked from every page |
| Cookie consent | Required if you set non-essential cookies; blocks them until consent |
| Terms and imprint | Present where your jurisdiction requires them |
| Analytics | Installed once, firing on all pages, with a goal set for the primary action |
| Search Console | Property verified and sitemap submitted on launch day |
| Keyboard access | Every interactive element reachable and operable with Tab and Enter |
| Contrast | Body text and controls meet WCAG AA against their backgrounds |
| Zoom | Page usable at 200% text size without horizontal scrolling |

### The first hour and the first week
Launch is not a moment, it is a window. Most problems that make it past the checklist appear in the first hour, and the SEO ones appear over the following days.
- Load the homepage from a phone on mobile data, not from the office network.
- Submit the main form yourself and confirm the notification arrives.
- Check five old URLs redirect correctly, including one deep one.
- Confirm analytics is recording your own visit, then exclude your traffic.
- Submit the sitemap in Search Console and request indexing for the top pages.
- Watch server error logs for the first hour — new traffic patterns surface new errors.
- After a week: check Search Console coverage for unexpected exclusions and crawl errors.
- After a week: compare traffic to the old site and investigate any page that lost heavily.
Do not launch on a Friday afternoon. If something breaks, the people who can fix it are gone for two days and the problem compounds.

Q: What is the most common launch mistake?
A: A robots.txt or a noindex meta tag carried over from staging to production. The site looks perfect to everyone who visits it and is invisible to search engines, and it is often discovered weeks later when someone asks why traffic never arrived. Check robots.txt and the meta robots tag on production, on launch day, from outside your network.

Q: Do I need to redirect old URLs?
A: If the old site had any traffic or any inbound links, yes. Map every old URL to its closest equivalent with a 301. Redirecting everything to the homepage is the same as deleting the pages as far as accumulated ranking signals are concerned, and it is a bad experience for anyone following an old link.

Q: How long before search traffic recovers after a relaunch?
A: With clean redirects and equivalent content, typically two to six weeks of fluctuation before things settle. A dip in the first fortnight is normal. A dip that keeps deepening after a month usually means a technical problem — missing redirects, blocked crawling, or content that was cut without anyone noticing.

Q: Should I launch everything at once or in phases?
A: For a site replacement, all at once is usually simpler: running two sites in parallel splits your links and creates duplicate content problems. For new sections on an existing site, phased is fine. What you should not do is launch half a structure and add the rest later without planning the URLs for what is coming.

## Freelancer, Agency or In-House: Which Fits Your Project?
https://websitedevelopment.biz/guides/freelancer-vs-agency-vs-in-house
Updated 2026-08-07 · Hiring developers

The same website can be built by one freelancer, by an agency team, or by someone you employ. The output can be similar; the risk profile, the cost and what happens in year two are not.

This guide compares the three by the factors that actually differ, and covers the hybrid arrangements most organisations end up with.

### The comparison that matters
Cost is the obvious axis and rarely the deciding one. Continuity usually is.
| Cost for one project | Lowest | Highest | High if it is one project |
| Cost over years | Low | Medium to high | Lowest if there is continuous work |
| Speed to start | Fast | Slower — queued | Slowest — recruitment |
| Range of skills | Narrow to medium | Broad | Whatever you hired |
| Continuity risk | High — one person | Low | Medium — they can leave |
| Process and QA | Varies enormously | Usually formalised | Whatever you build |
| Business knowledge | Grows over time | Shared across a team | Deepest |
| Best for | Defined projects, ongoing small work | Large projects, multiple skills | Continuous product work |

### The freelancer case, honestly
A good freelancer is the best value available for a well-defined project, and the arrangement has one specific failure mode you should plan around rather than ignore.
- The advantage: you talk to the person doing the work; there is no account-management layer and no margin on top of it.
- The risk: illness, another client, or simply moving on. A one-person supplier has no redundancy.
- Mitigations that work: code in your repository from day one, documented deployment, accounts in your name, and a second developer who has at least seen the project.
- Where it fails: projects needing several disciplines at once — design, back-end, integrations, QA — on a fixed deadline.
- Where it excels: ongoing small improvements, where a person who knows your site is worth far more than a team who does not.
The freelancer risk is not competence, it is availability. Every mitigation above is about making the project survivable without them, and all of them are cheap to arrange at the start.

### The agency case, honestly
You are buying capacity, breadth and continuity, and paying for the overhead that provides them.
- The advantage: several skills available at once, a process, and the project continues if someone leaves.
- The cost: account management, project management and margin, typically 40–60% above a freelancer for the same output.
- The risk: the people who pitched are not the people who build. Ask who will actually do the work and get names.
- Where it fails: small ongoing changes, which are inefficient against an agency’s cost structure and get deprioritised behind larger clients.
- Where it excels: a substantial build with a real deadline and several disciplines involved.

### In-house and the hybrids
Employing a developer only makes sense with continuous work — otherwise you are paying for idle capacity and, worse, a single person with no peer to review their decisions.
- In-house alone suits organisations where the website is a product with a roadmap, not a project that finishes.
- Agency builds, freelancer maintains is a common and sensible pattern: buy capacity for the build, buy continuity for the years afterwards.
- In-house plus specialists works when you have someone competent internally and bring in expertise for specific problems.
- Freelancer plus a named backup is the cheapest arrangement that has any redundancy at all.
- Agency retainer with a fixed monthly allocation works if the allocation is genuinely used; unused hours are pure cost.

Q: Is a freelancer riskier than an agency?
A: For continuity, yes — one person cannot be in two places or be ill without affecting the project. For quality, not inherently; the variance among freelancers is wide in both directions and so is the variance among agencies. The right comparison is not competence but what happens if your supplier becomes unavailable next month.

Q: How much cheaper is a freelancer?
A: Typically 30–50% for comparable output, because there is no project management layer, no account management and no agency margin. What you may lose is the process that catches problems — QA, code review, a second opinion — which is exactly the thing that is invisible until it is missing.

Q: When is it worth employing a developer?
A: When there is genuinely continuous work — a site that is a product, with a roadmap — and preferably when there will be more than one of them. A single in-house developer with no peer is a knowledge silo and a single point of failure, which is a similar risk to the freelancer case with a higher fixed cost.

Q: Can I mix approaches?
A: Most organisations end up doing exactly that, and it works well: an agency for the build, a freelancer or a small retainer for ongoing changes. The condition is that the handover is real — code in your repository, documented deployment, accounts in your name — otherwise the second party spends weeks reverse-engineering the first.

## How to Hire a Website Developer: A Practical Process
https://websitedevelopment.biz/guides/how-to-hire-a-website-developer
Updated 2026-08-07 · Hiring developers

Choosing a website developer is mostly a matter of evidence gathering, and most people gather the wrong evidence: portfolios, which show the best work rather than the typical work, and price, which compares things that are not comparable.

This guide covers a process that produces better outcomes — what to send out, what to ask, what to check, and when to stop.

### Send the same brief to everyone
Quotes are only comparable if they answer the same question. A one-page brief plus a page structure is enough, and it removes most of the variance that makes quotes look wildly different.
- What the site must achieve, and the one action that matters most.
- A page list, marked launch-critical or later.
- The functional requirements: forms, search, accounts, checkout, integrations.
- What is out of scope — content writing, photography, ongoing SEO.
- Your budget range. Withholding it wastes everyone’s time and produces quotes you cannot use.
- Your deadline and what is driving it.
- How you will decide, and by when.
Giving a budget range does not mean you will be charged the top of it. It means the proposals you receive will be for projects you can actually buy.

### What to ask, and what the answers mean
These questions separate developers who have finished projects from those who have started them.
| Show me a site like mine at my scale | A live URL, not a portfolio image, with context |
| Who owns the code and the accounts? | "You do" — immediately, without qualification |
| How does a change reach production? | Version control and a deployment process, not FTP |
| What happens if something breaks after launch? | A defined support window and what follows it |
| What is not included? | A specific list, offered without being pushed |
| What could make this project go wrong? | Honest risks — content delays, integrations, decisions |
| Who will actually do the work? | Named people, not "our team" |
| What do you need from us? | A clear list with dates |

### Check the evidence yourself
Twenty minutes of independent checking is worth more than an hour of conversation, because it tests the work rather than the pitch.
- Open two of their live sites on a phone, on mobile data.
- Run one through a performance test and look at the result honestly.
- Tab through a page with the keyboard and see whether focus is visible.
- View source: is there a title, a meta description, sane heading structure?
- Speak to one previous client — and ask specifically about a time something went wrong.
- Check whether their own site is maintained. It is not decisive, but it is a signal.
The most useful reference question is not "were you happy" but "what happened when something went wrong, and how did they handle it?" Every project has one of those.

### Red flags and green flags
Patterns worth weighting heavily in either direction.
| A quote within an hour, without questions | Questions about your business before quoting |
| Guaranteed first-page rankings | Explaining that nobody can guarantee rankings |
| Vague scope with a fixed price | An explicit out-of-scope list |
| They hold the domain or hosting | Everything registered in your name |
| No staging environment | You review on staging from the first template |
| Unwilling to give references | Offers them before you ask |
| Pressure to sign this week | Willing to wait while you compare |
| Full payment up front | Milestone payments tied to deliverables |

Q: Should I choose the cheapest quote?
A: Only if it is answering the same question as the others. A quote far below the rest usually excludes something — content entry, testing, post-launch fixes — or has not read the brief. Ask what is excluded, in writing, then compare total year-one cost including maintenance and what you own at the end.

Q: How do I judge a developer if I am not technical?
A: Judge process and evidence rather than technology. Can they show you a live site at your scale? Do they use version control and staging? Will they answer "who owns the code?" without hesitating? Do they ask about your business? None of that requires technical knowledge, and it predicts outcomes better than the stack does.

Q: What should be in the contract?
A: Scope with an explicit exclusions list, milestones and payments, ownership of code, domain and accounts, revision rounds, what happens after launch, response times for problems, and notice periods. If there is one clause to insist on, it is ownership — everything else can be renegotiated later, that one cannot.

Q: How many developers should I approach?
A: Three to five is the useful range. Fewer and you have nothing to compare; more and the effort of evaluating exceeds the value of the extra options, and you will keep everyone waiting. Send the same brief to all of them and set a decision date so the process ends.

## Responsive Web Design: A Practical Guide
https://websitedevelopment.biz/guides/responsive-web-design-guide
Updated 2026-08-07 · Web design

Responsive design means one site that works at any width, not a separate mobile version. In practice most sites are responsive on paper and broken in specific places — a table that forces horizontal scrolling, a navigation that eats a third of the screen, a form that zooms unpredictably on iOS.

This guide covers how to approach it, where the real failures are, and how to test for them.

### Design from the narrow end
Starting narrow forces the priority decisions. At 320 pixels there is room for one thing at a time, so you have to decide what that thing is; widening a design afterwards is mostly a matter of giving things more room.

Going the other way — designing at 1440 and then removing things — produces mobile layouts that are the desktop with pieces hidden, which is how important content ends up display:none on the device most visitors use.
- Start layouts at 320–360px, the narrowest real devices in common use.
- Never hide content on mobile that a mobile visitor needs; move it or fold it instead.
- Let content decide breakpoints — add one where the layout breaks, not at device names.
- Test with the browser text size at 200%: this is a common accessibility setting and it breaks more layouts than any phone.
Device-named breakpoints age badly. "Tablet" has meant six different widths in ten years; "the point where the card grid gets ugly" does not change.

### The elements that actually break
A handful of components account for most responsive failures, and they are predictable enough to check deliberately.
| Tables | Horizontal scroll on the whole page | Scroll container, or restack as cards with data labels |
| Long words / URLs | Page scrolls sideways | overflow-wrap and min-width:0 on flex and grid children |
| Images | Overflow or layout shift | max-width:100%, explicit width and height attributes |
| Navigation | Takes a third of the screen | Collapse, or move primary items to a bottom bar |
| Forms | iOS zooms in and will not zoom out | Font size at least 16px on inputs |
| Fixed elements | Cover the content they anchor to | Account for them in scroll-padding and body padding |
| Modals | Cannot be dismissed on a small screen | Full-screen on mobile with a visible close control |

### Images and media
Images are usually the largest thing on a page and the most common source of layout shift. Three attributes fix most of it and cost nothing.
- Always set width and height attributes so the browser reserves the space before the file arrives.
- Serve modern formats — WebP or AVIF — with a fallback where you still need one.
- Use srcset and sizes so a phone downloads a phone-sized file, not a 2000px hero.
- Lazy-load images below the fold, but never the largest visible image: that is your LCP element.
- Give the main image fetchpriority="high" so it is not queued behind decorative assets.
- For background images set an aspect ratio so the container does not collapse before load.

### Touch, not just width
Responsive is not only about layout. A narrow viewport usually means a finger rather than a mouse, and finger input has different requirements that width-based media queries alone do not address.
- Touch targets at least 44×44px with spacing between them; adjacent 30px links get mis-tapped constantly.
- Nothing important behind hover — a hover-only menu is unreachable on touch.
- Use pointer:coarse media queries to drop hover effects that stick after a tap.
- Keep primary actions within thumb reach on tall phones; the top-right corner is the hardest place to press one-handed.
- Respect prefers-reduced-motion: parallax and large transitions cause real discomfort for some users.

Q: How many breakpoints do I need?
A: Usually three to five, and they should come from your content rather than from a device list. Add one where the layout starts to look wrong as you widen the window, not because a particular phone exists. Sites with a dozen breakpoints are almost always compensating for a layout that was not fluid to begin with.

Q: Is a separate mobile site ever right?
A: Rarely. It means two codebases, two sets of URLs, two deployments and a canonical relationship to maintain, and it usually ends with one of the two quietly falling behind. The cases where it still happens are legacy systems that cannot be made responsive, and even then it is a stopgap rather than a plan.

Q: How do I test responsive design properly?
A: Browser device emulation catches layout problems but not touch, network or platform behaviour. Test on at least one real low-to-mid range Android and one iPhone, on mobile data rather than office wifi. Then repeat the key pages with browser text size at 200%, which is where most layouts actually fall apart.

Q: What about tables of data on phones?
A: Two workable options: put the table in a horizontally scrolling container with a visible affordance and a sticky first column, or restack each row as a card where every cell carries its own column label. The scroll container keeps comparison possible; the card stack is easier to read. Choose based on whether visitors compare rows or read one at a time.

## Website Structure and Sitemap: How to Plan Your Pages
https://websitedevelopment.biz/guides/website-structure-and-sitemap
Updated 2026-08-07 · Website planning

Site structure is the arrangement of your pages and the paths between them. It decides whether a visitor finds what they came for in one click or three, and it is one of the strongest signals a search engine has about what your site is about and which pages matter.

This guide covers how to plan a structure, how deep is too deep, how to name URLs, and the mistakes that are cheap to avoid now and expensive to fix after launch.

### Group by task, not by org chart
The most common structural mistake is a navigation that mirrors how the organisation is arranged rather than what visitors came to do. Nobody arrives looking for your Solutions Division.

Start from the questions visitors actually ask, group the pages that answer each one, and name the group in the words they would use — which are almost never your internal words.
- Write each page on its own line, then group lines that answer the same question.
- Name each group in visitor language: "Pricing", not "Commercial Framework".
- Aim for five to seven top-level sections; more than that and the navigation stops being scannable.
- If a page does not fit any group, it is usually either unnecessary or a new group of one — decide which.

### Keep important pages shallow
Depth is the number of clicks from the homepage. Pages that matter should be reachable in two or three; anything at depth five is rarely found by visitors and is crawled less often by search engines.

Depth is not the same as URL length. A page at /guides/seo/technical-seo can still be one click from the homepage if something links to it directly. What matters is the link path, not the slashes.
| 0 | Homepage | Links to every top-level section and the primary action |
| 1 | Section hubs, key landing pages | In the main navigation |
| 2 | Individual articles, products, services | Linked from hubs and from related content |
| 3 | Variants, deep reference pages | Linked from their parent and from search |
| 4+ | Archives, old campaigns | Question whether they should be indexed at all |
The homepage is not the main entrance for most sites. Search traffic lands deep, so every page needs to say where it is and offer the next step.

### URL patterns worth deciding once
URLs are cheap to get right at the start and painful to change afterwards, because changing them means redirects, lost signals and broken external links. Decide the pattern before the first page exists.
- Lower case, words separated by hyphens, no underscores or spaces.
- Short and descriptive: /guides/website-planning-guide, not /p?id=4821.
- One consistent decision on trailing slashes, enforced with a redirect to the canonical form.
- Include the section when it adds meaning; do not stack every ancestor into the path.
- No dates in URLs unless the content is genuinely time-bound — they make evergreen pages look stale.
- For multilingual sites, decide the language pattern now: /de/… prefixes are the simplest to reason about.

### Two sitemaps, two audiences
The word covers two different things. A planning sitemap is the diagram you draw before the build — pages and their relationships. An XML sitemap is a file at /sitemap.xml that lists your indexable URLs for search engines.

You need both, and they serve different readers.
| Audience | Your team and the developer | Search engines |
| When | Before design starts | Generated automatically after launch |
| Contains | Every planned page and its parent | Every canonical, indexable URL |
| Format | A diagram or a nested list | XML, split by section on larger sites |
| Maintenance | Updated when scope changes | Regenerated whenever content changes |
An XML sitemap should list only pages you want indexed. Including filtered, paginated or noindex URLs wastes crawl budget and sends contradictory signals.

Q: How many top-level navigation items should I have?
A: Five to seven for most sites. Beyond that the bar stops being scannable and starts being a list people read rather than glance at — and on a phone it becomes a menu nobody opens. If you genuinely need more, the usual fix is that two of your sections are actually one.

Q: Do URLs need to match the navigation?
A: They should be consistent but they do not have to mirror it exactly. What matters is that the URL is predictable and stable. Deeply nested paths that stack every ancestor are fragile: move one section and every URL underneath changes, and you inherit a redirect map you have to maintain forever.

Q: What happens to my old URLs in a redesign?
A: Every old URL that had traffic or links needs a 301 redirect to its closest equivalent. Not to the homepage — that tells a search engine the page is gone and loses the accumulated signals. Map the redirects before launch, from a crawl of the old site plus your analytics, and test them the day you go live.

Q: Should every page be in the navigation?
A: No. Navigation is for the pages most visitors need; the rest are reached through hubs, related links, search and the footer. A page that is in no navigation and linked from nowhere is orphaned, though — it will barely be crawled and rarely found. Every indexable page needs at least one internal link from somewhere.

## Website Design Principles That Actually Affect Results
https://websitedevelopment.biz/guides/website-design-principles
Updated 2026-08-07 · Web design

Plenty of website design advice is preference dressed as principle. A smaller number of decisions reliably change what visitors do, and they are mostly unglamorous: what is visible first, whether text can be read, and how many steps stand between someone and the thing they came for.

This guide covers the ones with evidence behind them and names the ones that are genuinely a matter of taste.

### One clear hierarchy per screen
Every screen should make one thing obviously most important. When three elements compete for attention with the same weight, visitors resolve the ambiguity by leaving.

Hierarchy is built from size, weight, colour, spacing and position — in that rough order of strength. Space is the most underused: an element with room around it reads as important without needing to shout.
- One primary action per screen, styled differently from everything else.
- Secondary actions present but visually quieter — outline instead of filled.
- Headings that describe content, not clever ones that describe nothing.
- Space used deliberately: a crowded page has no hierarchy, only density.

### Readability before decoration
Text that is hard to read costs you readers regardless of how good the writing is. These are measurable thresholds rather than opinions.
| Body text size | 16–18px on mobile | Below 16px iOS zooms on form focus and small text loses readers |
| Line length | 55–75 characters | Longer lines make the eye lose its place on return |
| Line height | 1.5–1.7 for body copy | Tight leading reduces reading speed measurably |
| Text contrast | 4.5:1 minimum, 7:1 better | WCAG AA; grey-on-grey fails outdoors on a phone |
| Control contrast | 3:1 against the background | Users must be able to see where an input ends |
| Paragraph length | Three to four lines | Long blocks are skipped on mobile |
Check contrast against the actual background, including gradients and images. A value that passes on white can fail on the hero it is actually placed over.

### Design forms for completion, not for symmetry
Forms are where most website goals are actually completed, and where most design attention is not spent. Every field you add costs completions; every field you remove is free money if you did not need the data.
- Ask for the minimum you need to respond. You can ask the rest in the reply.
- One column. Two-column forms cause skipped fields and are worse on mobile.
- Labels above fields, always visible — placeholder-only labels vanish as soon as typing starts.
- Correct input types and autocomplete attributes so phones show the right keyboard and offer to fill.
- Validate on blur, not on every keystroke, and put the error next to the field.
- Never clear the form on an error. Losing typed answers is the most common reason people abandon.
- Say what happens next after submission, and how long it takes.

### What is taste and what is not
Being clear about the difference saves a lot of review-meeting time. The left column is arguable; the right column is not.
| Colour palette | Contrast ratios against the real background |
| Typeface choice | Body text size and line length |
| Illustration style | Whether images have meaningful alt text |
| Hero image or no hero image | Whether the primary action is visible without scrolling |
| Rounded or square corners | Whether focus states are visible for keyboard users |
| Animation style | Whether animation respects prefers-reduced-motion |
| Layout density | Whether touch targets are at least 44px |

Q: Does "above the fold" still matter?
A: Not as a rule that everything important must fit there — people scroll, and have for twenty years. What matters is that the top of the page answers "what is this and is it for me?" within a couple of seconds. If it does, visitors will scroll for the detail. If it does not, nothing further down gets read.

Q: How many fonts should a website use?
A: Usually one or two families, with weights doing the work that extra families would. The practical reason is performance rather than taste: each additional family and weight is another file to download before text renders correctly. A single well-chosen family with three weights covers almost every site.

Q: Is dark mode worth building?
A: It is worth it if you can do it with design tokens from the start, when it costs very little. Retrofitting it onto a finished site means auditing every colour, every image and every shadow, which is a real project. If you support it, respect the system preference by default and let the user override it.

Q: Should the design match competitors?
A: Conventions should match — navigation at the top, basket at the top right, logo linking home — because breaking those costs comprehension for no gain. Everything above conventions is where you differentiate. The mistake is copying a competitor’s layout wholesale, which usually imports decisions that suited their content and not yours.

## How to Write a Website Requirements Document
https://websitedevelopment.biz/guides/website-requirements-document
Updated 2026-08-07 · Website planning

A requirements document exists so that you and the developer are describing the same website. It does not have to be long. A four-page brief that both sides have actually read prevents more disputes than a fifty-page specification that neither has finished.

This guide covers what belongs in it, what to leave out, and how to write the section that matters most: what the project is not.

### What a requirements document is for
It has three jobs: let several developers quote the same thing so the quotes are comparable, give you a reference when there is a disagreement about scope, and force you to make decisions while they are still cheap.

It is not a design brief, and it is not a technical specification. Saying "the site must load quickly" is a requirement; saying "use Redis for object caching" is a solution, and choosing it before you have hired anyone removes the expertise you are paying for.
- State outcomes and constraints, not implementations.
- Write it so someone outside your organisation can understand it without a call.
- Keep it short enough that it is read in one sitting — four to eight pages is plenty for most sites.
- Date it and version it, because it will change.

### The sections worth including
This structure covers most website development projects. Skip anything that does not apply rather than padding it out.
| Background | What the organisation does and why the site is being built or replaced |
| Goals | The primary goal, secondary goals, and how success is measured |
| Audience | Two or three visitor groups and the question each arrives with |
| Page structure | Every page, grouped into sections, marked launch-critical or later |
| Functional requirements | Forms, search, accounts, filtering, booking, checkout — what each must do |
| Integrations | Every external system, with a named contact and API documentation link |
| Content | Who writes each page, who approves it, when it is due |
| Non-functional | Performance, accessibility, browser and device support, languages, security |
| Out of scope | Explicitly excluded work — the most valuable section |
| Constraints | Budget range, deadline and any fixed decision (existing host, mandated CMS) |

### Write requirements you can test
A requirement is useful when both sides can agree afterwards whether it was met. "The site should be fast" cannot be tested; "the product listing page reaches Largest Contentful Paint under 2.5 seconds on a mid-range Android over 4G" can.

The same applies to functionality. "A contact form" leaves out every question that matters.
| A contact form | Six fields, spam protection, stores to database, emails two addresses, GDPR consent line |
| Mobile friendly | Usable at 320px, all touch targets at least 44px, no horizontal scroll |
| Fast | LCP under 2.5s and CLS under 0.1 on the four main templates, measured on 4G |
| Accessible | WCAG 2.2 AA on templates, verified with keyboard-only and screen-reader passes |
| SEO friendly | Editable titles and descriptions, clean URLs, sitemap, structured data on articles |
| Multilingual | Three languages, translated URLs, hreflang tags, language switcher on every page |

### The out-of-scope list
This is the section people skip and the one that saves the project. Write down the things a reasonable person might assume are included, and say plainly that they are not — or move them in, if they should be.

Doing this before quotes arrive means the quotes are comparable. Doing it afterwards means an argument.
- Content writing and proofreading — assume it is yours unless the quote says otherwise.
- Photography, illustration and stock licences.
- Content entry: who types 200 products into the CMS?
- Email setup, DNS migration and hosting account transfer.
- Ongoing SEO work as distinct from technical SEO setup at launch.
- Training, documentation and handover.
- Post-launch support: what is covered, for how long, and what is billable.
A good developer will add to this list unprompted. One who agrees to everything without questions has usually not read it, and the disagreement is simply deferred.

Q: How long should a requirements document be?
A: Four to eight pages covers most business websites. Stores and applications run longer because the functional section grows, but if it passes twenty pages ask what is being described that a conversation could not settle. The measure is whether both sides have read it, not whether it is comprehensive.

Q: Should I specify the technology?
A: Only where you have a genuine constraint: an existing CMS your team knows, a host you must stay on, a system that must be integrated. Otherwise state the outcome and let the people you are hiring choose the implementation. Specifying a stack you do not understand narrows your options and gives you a worse answer.

Q: Do I need wireframes as well?
A: Low-fidelity wireframes for the three or four most important templates remove a lot of ambiguity for very little effort, and they are far cheaper to change than a design. They are not a substitute for the written requirements — they show arrangement, not behaviour — but the two together price much more accurately than either alone.

Q: What if I do not know some of the answers?
A: Write "to be decided" and name who decides and by when. An honest gap with an owner is fine; an invented answer is not, because the quote will be built on it. Developers price uncertainty either way, so making the uncertainty visible usually gets you a better number than hiding it.

## The Web Design Process, Step by Step
https://websitedevelopment.biz/guides/web-design-process
Updated 2026-08-07 · Web design

Web design is not the part where someone chooses colours. It is a sequence of decisions that narrows from "what is this site for" down to "this button, this size, this label", and each step is cheaper to change than the one after it.

This guide covers the stages in order, what each one produces, and the two points where design projects reliably stall.

### Discovery: what the design has to achieve
Before anything visual, the designer needs the same things a developer needs: the primary goal, the audience, the page structure and the constraints. If they start without those, you get a design that looks good in a portfolio and fails when the real content arrives.

This stage produces agreement, not artefacts. A one-page summary that both sides accept is enough.
- The one action the site must drive, and how it will be measured.
- Two or three visitor groups and the question each arrives with.
- Brand constraints that genuinely exist: logo, colours, typefaces, tone.
- Technical constraints: the CMS, the platform, the devices that actually matter.
- Examples of sites the client likes — and, more usefully, why.

### Structure and wireframes
Wireframes settle arrangement and hierarchy without the argument about colour. They answer what is on each template, in what order, and what the visitor is meant to do — while changes still cost minutes.

Wireframe the templates, not every page. Most sites have four to eight distinct templates and dozens of pages built from them.
| Homepage | What is this and is it for me? | Go to the right section |
| Section hub | What is in here? | Choose an item |
| Article / detail | The actual answer | Read, then take the next step |
| Product | Is this the right one and what does it cost? | Add to basket |
| Contact / form | How do I start? | Submit |
| Search results | Did you find it? | Open a result or refine |
Wireframe with realistic content lengths. A layout designed around a six-word headline breaks the moment a real one runs to fourteen.

### Visual design and the design system
Visual design applies the brand to the wireframes: type scale, colour, spacing, states and components. On anything larger than a brochure site it is worth producing a small system — a set of components with defined states — rather than a set of unrelated page pictures.

The reason is not tidiness. It is that a system tells the developer what happens in cases the mockups do not show, and those cases are most of the site.
- A type scale and spacing scale, so nothing is a one-off number.
- Colour tokens with contrast checked against their actual backgrounds.
- Component states: default, hover, focus, active, disabled, loading, error, empty.
- Responsive behaviour for each component, not just a mobile version of the homepage.
- What happens with too much content, and with none.

### Where design projects stall
Two failures account for most of the delay, and both are process problems rather than taste problems.
- Feedback without an owner. Six people comment, two of them contradict each other, and the designer is left to arbitrate. Name one person who consolidates feedback and makes the final call.
- Content that does not exist. Designs are approved against placeholder text, then the real copy arrives at twice the length and the layout is redone. Design with real content, even rough real content.
- Unlimited revision rounds. Agree the number up front — usually two or three — and what a further round costs. Without a limit, projects drift rather than finish.
- Sign-off that is not sign-off. "Looks good" in a meeting is not approval. Get it in writing, per template, with a date.
The most useful question in a review is not "do you like it" but "does this help the visitor do the thing we agreed the site is for". Taste arguments have no end; goal arguments do.

Q: How many design revision rounds should I expect?
A: Two or three is normal for a template-based project. What matters more than the number is that it is agreed in writing along with the cost of an extra round. Unlimited revisions sound generous and in practice mean the project never reaches a decision, because there is no forcing function for anyone to commit.

Q: Should design and development be the same person or team?
A: On small projects one person doing both is efficient and avoids a handover. On larger ones they are genuinely different skills and separating them usually produces better work — provided the designer produces a system with states and responsive rules rather than a set of pictures. The handover is where the risk sits, not the split.

Q: Do I need a full design before development starts?
A: You need the templates designed, not every page. Development can start once the design system and the two or three most complex templates are settled; the rest can be finished while the build runs. Starting development with nothing settled means rework, and finishing every last page before writing code means paying for idle time.

Q: What deliverables should I get at the end?
A: Editable source files for every template and component, a stated type and colour scale, exported assets in the formats the build needs, and the responsive rules written down. Ask before you start whether you receive the source files or only exports — the difference matters the first time you need a small change without the original designer.

## How Much Does a Website Cost? Real Ranges by Project Type
https://websitedevelopment.biz/guides/how-much-does-a-website-cost
Updated 2026-08-07 · Website planning

Any single figure for "a website" is misleading, because the same phrase covers a five-page brochure site and a store with 4,000 products and three system integrations. What is useful is the shape of the ranges and what moves you between them.

This guide covers typical costs by project type, the factors that actually drive the number, the running costs that rarely appear in a quote, and how to compare two quotes that differ by a factor of five.

### Typical ranges by project type
These are broad market ranges for professional work, not quotes. Regional rates vary widely, and the same brief costs less from a solo freelancer than from an agency with a project manager and a QA process — you are buying different amounts of risk cover, not just different amounts of code.
| Template / builder site | $500 – $3,000 | Existing theme, your content, light customisation |
| Small business site | $3,000 – $12,000 | Custom design, CMS, 5–15 pages, basic SEO setup |
| Mid-size custom site | $12,000 – $50,000 | Bespoke design system, custom templates, integrations |
| Online store | $5,000 – $80,000+ | Platform, catalogue, payment, shipping, tax, migration |
| Web application | $40,000 – $250,000+ | Custom logic, accounts, permissions, ongoing releases |
| Redesign of an existing site | 60–90% of a new build | Rarely cheaper than starting fresh once migration is counted |
A redesign is usually not a discount. Migrating content, preserving URLs and matching existing behaviour is work that a new build does not have.

### What actually drives the number
Page count is a weak predictor of cost. Twenty pages built from three templates is cheaper than five pages that are all different. What moves the price is custom logic, integrations and content volume.
- Number of distinct templates, not number of pages. Each unique layout is design plus build plus QA.
- Integrations. Every system the site must talk to — CRM, ERP, payment, booking, email — adds work and adds a thing that can break.
- Content migration. Moving 40 pages by hand is an afternoon; moving 4,000 products with images and variants is a project of its own.
- Languages. A second language is rarely double, but it is never free: structure, URLs, hreflang and a translation workflow.
- Custom logic. Pricing rules, configurators, permissions and workflows are where budgets actually go.
- Accessibility and performance targets. Meeting a standard is cheaper designed in than retrofitted, but it is not zero either way.

### The costs that are not in the quote
A build quote is the start of the spending, not the end. The running costs are individually small and collectively significant, and they arrive whether or not anyone mentioned them.
| Domain | $10 – $50 | Make sure it is registered in your name, not the agency’s |
| Hosting | $60 – $3,000+ | Shared to managed cloud; a store needs more than a brochure site |
| SSL certificate | $0 – $200 | Free is fine for most sites |
| CMS / platform fees | $0 – $30,000+ | eCommerce platforms often also take a percentage of revenue |
| Plugins and licences | $100 – $2,000 | Renewals are easy to forget until something stops working |
| Maintenance and updates | 10–20% of build cost | Security patches, backups, small fixes |
| Content and photography | Highly variable | Frequently the largest unbudgeted line |

### How to read a quote that looks too cheap
A quote well below the others is not automatically bad, but it is always answering a different question. Find out which one before you compare on price.
- Ask what is excluded, in writing. Content entry, SEO setup, training and post-launch fixes are the usual omissions.
- Ask who owns the code, the domain and the hosting account after launch. If the answer is not "you", the price is not the price.
- Ask how many revision rounds are included and what round four costs.
- Ask what happens if something breaks in week two: covered, hourly, or a new project?
- Ask to see a live site they built at your scale — not their best-looking work, their most similar work.
- Compare the total for year one, not the build number. That is where cheap quotes stop being cheap.
The two quotes worth worrying about are the one that is a third of the others and the one that arrives within an hour of the brief. Both usually mean the brief was not read.

Q: Why do quotes for the same brief differ so much?
A: Because they are pricing different amounts of risk and different amounts of process. A solo developer prices their own hours. An agency prices a designer, a developer, a project manager, QA, and the cost of fixing it if the person who built it leaves. Neither is wrong; they suit different projects and different tolerances for things going wrong.

Q: Is a monthly subscription website a good deal?
A: It depends what happens when you stop paying. Some subscriptions bundle build, hosting and maintenance and you keep nothing if you leave — over three or four years that usually costs more than owning a site outright. Others are genuine managed services with an exit path. Ask what you own and what happens on cancellation before comparing the monthly number to anything.

Q: Should I pay a deposit?
A: A deposit is normal — typically 30–50% up front with the balance on milestones or launch. What is not normal is paying the full amount before anything exists. Tie payments to deliverables you can see, and make the final payment due on launch rather than on an internal sign-off you cannot verify.

Q: How much should I budget for maintenance?
A: Plan for 10–20% of the build cost per year for a CMS-based site: security updates, plugin renewals, backups, small content changes and occasional breakage. A store or an application needs more, because more of it is moving. Sites that skip maintenance do not save the money; they spend it later on an emergency.

## How to Plan a Website: The Complete Planning Guide
https://websitedevelopment.biz/guides/website-planning-guide
Updated 2026-08-07 · Website planning

Most website development projects do not run late because the code was hard. They run late because the plan was thin: nobody agreed what the site had to achieve, who would write the text, or what "done" meant.

This guide covers the planning work that happens before design and build, in the order it is actually useful, and the decisions that are expensive to change later.

### Start with one job the site has to do
A website that has to do everything usually does nothing measurably. Before anything else, write down the one action that matters most: a form submission, a phone call, a purchase, a booking, a download.

Everything downstream — page structure, navigation, what goes above the fold, how much you should spend — falls out of that answer. A site whose main job is generating enquiries is a different build from a site whose main job is selling 4,000 products.
- Primary goal: the one action you would keep if you could only keep one.
- Secondary goals: useful but not worth compromising the primary for.
- How you will measure it: a number you can check next quarter, not "more traffic".
- What the site does not need to do: written down, so it stays out of scope.
If two people in your organisation would name different primary goals, that disagreement will surface in week six of the build. Resolve it in week zero, when it costs a meeting instead of a rebuild.

### Know who is arriving and what they came for
Audience research does not need to be a formal exercise. What you need is a short, honest description of the two or three groups who actually visit, what question each one arrives with, and what would make them leave.
| First-time buyer | Can these people do what I need? | No proof, no prices, no clarity |
| Returning customer | Where is the thing I need now? | The task is buried three clicks deep |
| Someone comparing | How is this different from the others? | Generic copy that could be any competitor |
| A job applicant | What is it like to work here? | No careers page, or one that is stale |

### Decide the pages before you decide the design
Page structure is the cheapest thing to change on paper and one of the most expensive things to change after a design is signed off. List every page, group them into sections, and mark which ones are needed for launch and which can come later.

The common failure is a structure that mirrors your org chart rather than the visitor's task. Nobody arrives looking for your "Solutions Division"; they arrive looking for the thing they need.
- List every page you think you need, one per line, without grouping.
- Mark each as launch-critical or later. Be strict: most sites launch with fewer pages than planned.
- Group the launch-critical ones into no more than five or six top-level sections.
- Write the one sentence each page has to deliver. If you cannot, the page probably should not exist.
- Check the primary goal is reachable in one click from every top-level page.

### Content is the critical path — plan it first
Text, photographs and product data hold up more launches than any technical problem. The build finishes and the site sits in staging for six weeks waiting for an About page.

Decide now who writes each page, who approves it, and when it is due — and treat those dates as seriously as the development milestones. If nobody internally has time, budget for a copywriter; it is cheaper than an idle development team.
- Name an owner and a due date for every page of text, not "marketing".
- Decide what happens to existing content: migrate, rewrite or drop. Most of it should be dropped.
- Book photography early — it has the longest lead time of anything on the list.
- For a store, export and clean the product data before the build starts, not during.
- Agree who has final approval. Two approvers with equal authority is a schedule risk.
A useful test: if the site were finished tomorrow, could you fill it? If the answer is no, content is your real deadline.

### Set a budget range and a decision on the build approach
Planning ends with two numbers and one choice: what you can spend, when you need it live, and whether this is a template build, a CMS build or a custom build. Those three decide who you should even be talking to.
| Website builder | Small brochure site, no unusual requirements | You hit a ceiling and have to start again |
| CMS (e.g. WordPress) | Content-led site, frequent updates by non-developers | Plugin sprawl and ongoing maintenance |
| eCommerce platform | Selling products, standard checkout needs | Platform fees and limited customisation |
| Custom build | The site is the product, or integrations rule others out | Highest cost, and you own the maintenance |

Q: How long should planning take?
A: For a small business site, one to two weeks of real work — not elapsed time. For a store or an application, three to six weeks, most of it spent on content inventory and product data rather than on documents. If planning is taking months, it usually means the primary goal has not been agreed and the discussion is circling.

Q: Do I need a formal requirements document?
A: You need something written that both sides can point at, but it does not have to be long. A page structure, a list of features that are in scope, a list of things explicitly out of scope, and a content owner per page will prevent more disputes than a fifty-page specification nobody reads. The out-of-scope list is the part people skip and the part that saves the project.

Q: Should I plan the design at this stage?
A: Plan the structure, not the look. Deciding what pages exist and what each one has to achieve is planning; choosing colours and typefaces is design, and doing it before the structure exists means the design gets rearranged as soon as the real content arrives. Wireframes are the useful middle ground.

Q: What if the requirements change mid-project?
A: They will. What matters is that you agreed in advance how changes are handled: who can request one, who prices it, and whether it moves the launch date. A project with a change process runs late in a controlled way; a project without one runs late in an argument.

## The Website Development Tools That Actually Matter
https://websitedevelopment.biz/guides/best-website-development-tools
Updated 2026-08-07 · Website development

Tool lists date quickly and rarely help someone commissioning a website. What lasts is the set of *categories* a competent project uses, and what their absence tells you about how the project will go.

This guide covers the tooling categories that matter, what each one prevents, and the questions that reveal whether a developer works this way.

### The non-negotiable categories
These are not preferences. A project without them accumulates risk that surfaces at the worst moment — usually when something breaks and nobody can tell what changed.
| Version control | Lost work, unexplained changes, no way to roll back | "Which repository is the code in and can I have access?" |
| Staging environment | Testing in production | "Where do I review before it is live?" |
| Automated deployment | A person hand-copying files at 6pm on a Friday | "How does a change get to production?" |
| Backups | Total loss | "How often, where to, and when did you last restore one?" |
| Error monitoring | Silent failures nobody notices for weeks | "How do you find out something broke?" |
| Uptime monitoring | Finding out from a customer | "Who is alerted when the site is down?" |
| Dependency updates | Known vulnerabilities left in place | "How are security updates applied?" |
The strongest single signal is the answer to "how does a change get to production?". If it involves dragging files into an FTP client, everything else on this list is probably missing too.

### Build and front-end tooling
This is where fashion moves fastest and where it matters least to you as a client. What matters is the outcome, not the tool that produced it.
- A build step that minifies, bundles and optimises assets — page weight is a conversion problem, not a purity problem.
- Image pipeline producing modern formats and multiple sizes automatically. Hand-exported images are never kept up to date.
- A CSS approach with a system — variables, tokens, whatever the naming — rather than accumulating one-off rules.
- Only the JavaScript the page needs. A framework is a legitimate choice for an application and usually overhead for a brochure site.
- Browser support defined in writing. "Modern browsers" is not a specification.

### Testing and quality tooling
Full automated test suites are rarely justified on a marketing site. A small amount of automation on the paths that cost money is almost always justified.
- Automated checks on the critical paths only: checkout, sign-up, the main contact form.
- A performance budget checked automatically — a number that fails a build, not a hope.
- Automated accessibility scanning in the pipeline, knowing it catches about a third of issues.
- Cross-browser checks on the browsers your analytics actually shows, not a list of everything.
- A staging content set that mirrors real content lengths, including the awkward ones.
A performance budget is the highest-value automation for a content site: without one, page weight rises quietly every month and nobody is responsible.

### What you should have access to
Regardless of which tools the developer prefers, these accounts should be in your name from the first day. It is far easier to arrange at kickoff than after a relationship has ended.
- Domain registrar — in your organisation’s name, with your billing details.
- Hosting account, with the developer added as a user rather than as the owner.
- Code repository, with your organisation as owner.
- Analytics and Search Console properties.
- Any third-party service the site depends on: payment, email, CDN, error monitoring.
- A written list of these, kept somewhere your team can find it.

Q: Do I need to understand these tools?
A: No, but you should ask whether they exist and who has access. The questions in the table above are answerable in a sentence each by any competent developer, and hesitation on the deployment and backup questions is a genuine signal rather than a matter of style.

Q: Is a JavaScript framework necessary?
A: For a web application, usually yes. For a marketing or content site, usually not — and it often costs performance for no benefit, because the browser has to download and execute a framework before showing text that could have been in the HTML. The right question is what problem it solves on your site, and "it is what we use" is not an answer.

Q: What is a performance budget?
A: An agreed limit — for example, under 200KB of JavaScript and Largest Contentful Paint under 2.5 seconds on the main templates — that is checked automatically and fails the build when exceeded. It works because it converts performance from something everyone agrees is important into something that blocks a deploy.

Q: How do I know if the site is being maintained?
A: Ask for a monthly note: what was updated, what was patched, what the uptime was, and any errors that came up. If a maintenance retainer produces no report, it is difficult to tell the difference between careful maintenance and none, and you usually find out during an incident.

## Custom Website Development vs Templates: How to Choose
https://websitedevelopment.biz/guides/custom-website-development-vs-templates
Updated 2026-08-07 · Website development

A template is a pre-built design and codebase you configure. A custom build is made for your requirements. Templates are cheaper and faster right up to the point where you need something the template does not do — and then they are more expensive than starting custom would have been.

This guide covers where that point usually is, what the real cost difference looks like over a few years, and the hybrid approach that suits most sites.

### The honest comparison
Both approaches are legitimate. The question is which set of constraints you would rather live with for the next three years.
| Up-front cost | Low | High |
| Time to launch | Days to weeks | Weeks to months |
| Performance | Often poor — carries features you never use | As good as you pay for |
| Design distinctiveness | Recognisably a template | Yours |
| Unusual requirements | Fights you | Designed in |
| Maintenance | Depends on the vendor continuing to exist | Yours to schedule |
| Migration away | Hard — logic lives in theme settings | Easier — it is your code |

### Where templates hit a ceiling
The ceiling is rarely visual. Templates can usually be restyled convincingly. What they resist are structural requirements, and these are the ones that appear six months after launch.
- A content type the template did not anticipate. Case studies with structured fields, a directory, an events calendar with logic.
- Integrations. The template assumes its own contact form; you need the data in your CRM with your field mapping.
- Performance targets. Templates ship every feature for every buyer, so you download a page builder, a slider library and three icon fonts you never use.
- Accessibility. If the template’s components are inaccessible, fixing them means editing the theme — which breaks updates.
- Multilingual structure. Bolt-on translation plugins produce URL structures that are hard to undo later.
- Editorial workflow. Multiple authors, approvals and scheduling are usually beyond what a theme provides.
The expensive pattern is not choosing a template. It is choosing a template and then paying a developer to fight it for two years.

### Total cost over three years
Comparing build prices alone flatters the template. The relevant comparison includes licences, plugins, the developer time spent working around limitations, and what happens when the theme is abandoned.
| Initial build | Low | High |
| Theme and plugin licences | Annual, and they rise | None |
| Workaround development | Accumulates every year | Low |
| Performance remediation | Common | Rare if built well |
| Major version upgrade | Can break customisations | Controlled |
| Vendor abandons the product | Forced rebuild | Not applicable |
For a genuinely simple site the template still wins over three years, comfortably. The crossover arrives with the first structural requirement the theme does not have.

### The hybrid most sites actually need
The common middle path is a custom theme on an established platform: you get the CMS, the ecosystem and the security updates, and the front-end is yours rather than a purchased theme's.
- Use an established CMS or commerce platform — do not rebuild content management from scratch.
- Build the front-end templates yourself instead of buying a theme. This is where performance and distinctiveness live.
- Use plugins only for genuinely commodity functions: payment, SEO metadata, backups, forms.
- Write custom code for anything specific to your business, so it is not hostage to a plugin author.
- Keep the number of dependencies deliberately small; each one is an update, a licence and a possible breach.

Q: Can I start with a template and go custom later?
A: Yes, and it is a reasonable plan if you go in knowing the migration is a real project. Keep the content structure clean and portable from day one — that is the part that determines whether the move later is a week or a quarter. What makes migration painful is business logic buried in theme settings and plugin configuration, so keep as little there as possible.

Q: Are templates bad for SEO?
A: Not inherently, but many are slow, and speed is a ranking factor and a conversion factor. The common problems are bloated JavaScript, unoptimised images, and markup that makes proper heading structure and structured data awkward. A well-chosen minimal template can be perfectly good; a page-builder theme with forty modules usually is not.

Q: How do I judge a template before buying?
A: Run the live demo through a performance test and look at the page weight and script count, not the marketing page. Check the update history — a theme last updated eighteen months ago is a liability. Try the demo with a keyboard only. And check the support forum for how the author responds to bug reports, which predicts your next three years.

Q: Is custom worth it for a small business?
A: For a straightforward brochure site, usually not — the money is better spent on content and photography, which move results more. It becomes worth it when the site does something specific to your business: a configurator, an unusual booking flow, an integration with the system you run operations on. Distinctive appearance alone rarely justifies the difference.

## The Website Development Process Explained
https://websitedevelopment.biz/guides/website-development-process
Updated 2026-08-07 · Website development

Every website development methodology arranges the same phases differently. Understanding the phases themselves — what each produces and what closes it — is more useful than the name of the methodology, because it tells you whether the project is where it should be.

This guide covers the seven phases, typical durations for a mid-sized site, and what a real sign-off looks like at each one.

### The seven phases
Durations here assume a mid-sized custom site with a small team. They stretch with content volume and integrations far more than with page count.
| 1. Discovery | Goals, audience, scope, constraints | 1–2 weeks |
| 2. Structure | Page structure, content model, wireframes | 1–2 weeks |
| 3. Design | Templates, component system, responsive rules | 2–4 weeks |
| 4. Build | Working templates, CMS, integrations | 4–10 weeks |
| 5. Content | Real text, images and data in the system | Runs in parallel — often the longest |
| 6. Test | Functional, cross-browser, performance, accessibility | 1–2 weeks |
| 7. Launch | Live site, redirects, monitoring, handover | 2–5 days |
Phase 5 is the one that overruns. It is drawn as parallel because it should start in phase 2, not because it is small.

### What closes each phase
A phase is not finished because time has passed. It is finished when a specific thing has been agreed, in writing, by someone with authority. Without that, work continues on a foundation that can still move.
- Discovery: a signed scope with an explicit out-of-scope list.
- Structure: an approved page structure and content model, with field names your team understands.
- Design: approved templates for every distinct layout, including mobile and empty states.
- Build: each template demonstrated on staging with realistic content.
- Content: every launch-critical page filled and proofread by a named person.
- Test: an issue list agreed and split into launch blockers and post-launch fixes.
- Launch: a completed pre-launch checklist and confirmed access handover.

### Waterfall, agile, or something in between
The genuine difference is when scope is fixed. Fixed-scope projects price precisely and handle change badly; iterative projects handle change well and cannot promise a fixed total. Most website work sits in between: fixed scope for the launch, iterative afterwards.
| Price | Known up front | Rate per sprint or per month |
| Change | Formal change request, repriced | Absorbed by reprioritising the backlog |
| Best for | Clear, stable requirements | Evolving products and unclear requirements |
| Risk to you | Paying for something that no longer fits | Cost drifting without a hard stop |
| Needs from you | Decisions up front | Continuous availability to prioritise |
Beware fixed price with vague scope. It is the worst combination: the developer protects the margin by interpreting ambiguity narrowly, and every clarification becomes a negotiation.

### Where the process usually goes wrong
The same four failures account for most overruns, and none of them are technical.
- Design approved against placeholder content. Real copy arrives at double the length and the layout is rebuilt.
- Integrations discovered late. "It also needs to talk to our stock system" in week eight is a new project, not a change.
- No single decision-maker. Feedback arrives from five people, two of them disagree, and nobody has authority to settle it.
- Testing treated as a phase rather than a habit. Bugs found in week ten that were introduced in week three cost several times more to fix.

Q: How long does a typical website take?
A: A template-based small site is two to four weeks. A mid-sized custom site is typically three to five months end to end. Stores and applications run longer. The variable that moves these most is not complexity of code but availability of content and speed of decisions on the client side.

Q: Can phases overlap?
A: Some should. Content should start during structure, and testing should run throughout the build rather than only at the end. What should not overlap is design and build of the same template — building against a design that is still moving guarantees rework, and it is the most common source of "we already built that" arguments.

Q: What if we need to change something mid-project?
A: Expect to, and agree the mechanism in advance: who can request a change, who prices it, and whether it moves the launch date. Small changes absorbed silently are how a project drifts a month without anyone being able to say when it happened. A written change log solves most of this.

Q: Should I pay per phase?
A: Milestone payments tied to deliverables you can inspect are the fairest structure for both sides — typically a deposit, then payments at design approval, build completion and launch. Avoid paying entirely up front, and avoid paying entirely on completion, which pushes all the cash-flow risk onto the developer and usually costs you more.

## How Does Website Development Work? The Full Process
https://websitedevelopment.biz/guides/how-does-website-development-work
Updated 2026-08-07 · Website development

From the outside, website development can look like a long silence followed by a finished site. In practice it is a sequence of environments, checkpoints and decisions, and the client side has obligations at nearly every one of them.

This guide covers how a project actually runs, what you will be asked for and when, and the checkpoints where a problem is still cheap to fix.

### Environments: where the site lives before it is live
Almost every professional project runs three copies of the site. Knowing which one you are looking at prevents a large amount of confusion during review.
| Local | The developer | Day-to-day work; you never see this |
| Staging | You and the developer | Review, testing and sign-off — blocked from search engines |
| Production | Visitors | The live site |
Content added on staging does not automatically appear on production unless the project is set up to migrate it. Ask early, because typing 200 products twice is a real risk.

### The sequence of a typical build
Names differ between teams, but the order is fairly consistent because each step depends on the one before it.
- Kickoff. Requirements confirmed, access granted, contacts named, dates agreed.
- Setup. Repository, environments, CMS or framework installed, deployment pipeline.
- Templates. The design becomes working templates, usually most complex first.
- Content modelling. Fields and content types so your team can edit without breaking layouts.
- Integrations. Payment, CRM, email, analytics — each needs credentials from you.
- Content entry. Yours or theirs, depending on what the quote said.
- Testing. Functional, cross-browser, performance, accessibility.
- Pre-launch checks. Redirects, robots, sitemap, analytics, backups.
- Launch. DNS change, verification, monitoring.
- Post-launch. Fixes, handover, training, then maintenance.

### What your side has to deliver, and when
Most delays that look like developer delays are waiting-on-client delays. These are the items to have ready before they are asked for, because each one blocks work when it is late.
| Domain and DNS access | Setup | Launch cannot be scheduled |
| Brand assets and logo files | Templates | Placeholder branding through review |
| Page content and images | Content entry | The most common cause of a missed launch date |
| Product data | Content entry | Store build stalls entirely |
| Third-party credentials | Integrations | Integration work is blocked mid-sprint |
| Feedback on each review | Every checkpoint | Rework, because the build has moved on |
| Legal pages | Pre-launch | Launch delayed for a privacy policy |

### Checkpoints where a problem is still cheap
Cost of change rises sharply through a project. These are the moments to look properly rather than skim, because after each one the same change costs several times more.
- After wireframes: structure and priority are still free to change.
- After the first template is built: this is where you find out whether the design survives real content.
- After content modelling: try editing a page yourself. If it is awkward now, it will be awkward for years.
- After the first integration: confirm the data lands where your team actually works.
- On staging with real content: the last point at which layout problems are cheap.
- Before DNS change: redirects, analytics and forms verified.
Reviewing on a phone is not optional. Most sites get most of their traffic from phones, and desktop-only review is how mobile problems reach production.

Q: How much of my time will the project take?
A: More than most people budget. Expect a weekly checkpoint of thirty to sixty minutes, plus content work that is measured in days rather than hours. The single biggest predictor of a project finishing on time is whether the client side has one person with the authority to decide and the time to review.

Q: What is a sprint and do I need to care?
A: A sprint is a fixed period — usually one or two weeks — in which an agreed set of work is completed and shown to you. You care about it because it defines the rhythm of decisions: feedback given during a sprint is cheap, and feedback given three sprints later is rework. If your developer does not work in sprints, you still want a regular checkpoint for the same reason.

Q: Can I see progress before the site is finished?
A: Yes, and you should. Ask for staging access from the first template onwards. Seeing partial work is uncomfortable but it is far better than a reveal at the end, when structural feedback is expensive. Expect it to look unfinished — that is the point of looking early.

Q: What happens immediately after launch?
A: A short period — commonly two to four weeks — where small fixes are covered, then a transition to a maintenance arrangement or to nothing at all. Agree in advance which it is, what counts as a fix versus a new request, and who to contact out of hours if the site goes down. "We will sort it out later" is how sites end up unmaintained.

## What Is Website Development? A Complete Guide
https://websitedevelopment.biz/guides/what-is-website-development
Updated 2026-08-07 · Website development

Website development is the work of turning a design and a set of requirements into a site that runs: the markup and styling a visitor sees, the server logic and data behind it, and the deployment and maintenance that keep it working.

This guide covers what the term includes, how it differs from web design, what the front-end and back-end split actually means in practice, and which parts a given project needs.

### What the term covers
"Website development" is used for everything from installing a theme to building a bespoke application. What is consistent is the sequence: requirements become templates, templates become pages, pages get data, and the whole thing gets deployed, measured and maintained.

Design decides what it looks like and how it behaves. Development makes it exist, work at speed, survive real content and keep working after launch.
- Front-end: the HTML, CSS and JavaScript that runs in the visitor’s browser.
- Back-end: the server-side code, database and APIs that supply and store data.
- CMS work: templates and fields so non-developers can edit content safely.
- Integrations: payment, CRM, email, analytics, shipping, booking, ERP.
- Infrastructure: hosting, domains, certificates, CDN, backups, deployment.
- Quality: testing, performance, accessibility, security, monitoring.

### Website development vs web design
The two words are often quoted together and are genuinely different jobs. On small projects one person does both; on larger ones they are separate people, and knowing which you are buying prevents a common category of dispute.
| Question | What should it look like and how should it behave? | How is it built so it works? |
| Output | Wireframes, visual designs, a component system | Working templates, data models, a deployed site |
| Main tools | Design software, prototyping tools | Code editors, version control, build tools, a CMS |
| Fails as | A site that is confusing or off-brand | A site that is slow, breaks, or cannot be edited |
| Changes cost | Minutes at wireframe stage | Hours to days once built |
If a quote does not distinguish them, ask what happens if you already have a design. The answer tells you which work is actually being priced.

### Front-end and back-end in practice
The split is about where code runs, not about seniority. Front-end code executes in the visitor's browser, so it deals with rendering, interaction, responsiveness and accessibility. Back-end code runs on a server, so it deals with data, authentication, business rules and integrations.

A marketing site can be almost entirely front-end with a CMS supplying content. A store or an application needs substantial back-end work because money, stock and accounts have rules that cannot be trusted to a browser.
| Brochure site on a CMS | Most of the work | Templates and fields only |
| Content site with search and filtering | High | Moderate — indexing and queries |
| Online store | High | High — catalogue, checkout, tax, fulfilment |
| Booking or scheduling site | Moderate | High — availability, conflicts, notifications |
| Web application | High | Very high — accounts, permissions, business logic |

### What a website development project actually delivers
Beyond "the site", these are the deliverables worth naming in the agreement — because their absence is only noticed when you need them, usually when the original developer is no longer available.
- The source code, in a repository you have access to.
- Access to hosting, domain and any third-party accounts, in your name.
- A documented way to deploy a change, not one person who knows how.
- A CMS or admin area with the content types your team actually edits.
- Backups that have been restored once, so you know they work.
- Documentation of the integrations and where their credentials live.
- Training or a handover session for whoever maintains the content.
The single most valuable clause in a website development contract is the one that says you own the code and the accounts. Everything else can be renegotiated; that one cannot, once the relationship ends.

Q: Is website development the same as web development?
A: They are used interchangeably in most contexts. "Web development" is slightly broader and often includes web applications and APIs that are not really websites; "website development" usually implies a site with pages and content. In a brief, the distinction that matters is not the phrase but whether the project has custom business logic — that is what changes the cost and the skill set.

Q: Do I need a developer if I use a website builder?
A: Often not for a simple site, and that is a legitimate choice. You may still want one for the things builders do badly: performance, structured data, integrations with your existing systems, and migrating away later. A common pattern is to build it yourself and bring in a developer for a specific problem rather than for the whole site.

Q: What is a full-stack developer?
A: Someone who works on both the front-end and the back-end. For small and mid-sized website projects a competent full-stack developer is usually the most efficient hire, because the handover cost between two specialists exceeds the depth benefit. On large projects the specialisation is worth it, because the depth required on each side grows faster than one person can cover.

Q: How much of a website is code versus content?
A: By effort, content is usually the larger half and it is nearly always the schedule risk. A build can be finished and the site can still be weeks from launch because product descriptions, photographs and legal pages are not written. Plan the content with the same seriousness as the development milestones and the launch date becomes achievable.