Kate KightA guide to website infrastructure

Overview How the parts fit together

Anatomy of
a website.

A website is not one product. It is a collection of systems that establish an address, route requests, run code, manage content, store information, deliver files, and connect to outside services.

Those systems are often bundled by one vendor, which can make the boundaries hard to see. Understanding the layers helps teams choose an appropriate stack, assign ownership clearly, and change one part without rebuilding everything.

Following a request

What happens after someone enters a URL?

The sequence is fast enough to feel like a single action, but several independent systems participate.

1The browser finds the destination. The domain is looked up through DNS, which returns the technical directions for the website.
2The connection is secured and routed. A CDN or edge service may terminate HTTPS, apply security rules, and serve cached files.
3The host produces a response. It may return stored files or run application code that assembles the requested page.
4Content and data are retrieved. The application may query a CMS, database, media store, or outside API.
5The page continues communicating. Forms, payments, analytics, search, and monitoring may run after the page appears.

Terms that are often confused

A domain is not a website. It is the address that points toward one.

A registrar is not necessarily the DNS provider. One manages the registration; the other publishes routing records.

DNS is not hosting. It supplies directions to the host and to services such as email.

A host is not the platform. The host runs the site; the platform or framework shapes how it is built.

A platform is not always a CMS. Some platforms include editing, while others use a separate content system.

A code repository is not the live site. It stores source and history; a deployment turns that source into a running service.

Layers 1–5 Identity, routing, and delivery

The infrastructure that
gets a page to a visitor.

These layers establish control of the public address and determine how requests reach a working site. Mistakes here can affect the website, email, security, or all three at once.

Domain name

The public address

A domain is the human-readable name people use to reach a website, such as example.com. It is not the website itself, and buying one does not create hosting, email, or pages. It is a durable piece of identity that points people toward those services.

Decisions to make: Choose a name people can remember and spell, decide which extensions matter, and make renewal difficult to miss. The organization—not an employee, contractor, or agency—should be the registrant whenever possible.
How to explain it: “This is your address on the web. You should control it even when someone else manages the website.”
Ownership and exit check: Can the client renew, recover, unlock, and transfer the domain without relying on the developer?

Registrar

The keeper of the registration

The registrar is the company authorized to register and renew a domain. It maintains the account that controls transfer locks, contact information, nameserver settings, and renewal. A registrar may also sell hosting or email, but those are separate services.

Decisions to make: Prioritize strong account security, transparent renewal pricing, clear transfer controls, and reliable recovery. Use an organization-owned account with more than one trusted administrator and phishing-resistant multi-factor authentication when available.
How to explain it: “The registrar is where the deed to your web address is kept. Losing this account can mean losing the address.”
Ownership and exit check: Is the ownership information accurate, and can the organization obtain the transfer code itself?

DNS

The routing system

The Domain Name System translates a domain into directions computers can follow. Its records route the website, email, verification services, subdomains, and sometimes security policies. Changing DNS does not move the underlying services; it changes the signs pointing toward them.

Decisions to make: Know who hosts the DNS zone, who may edit it, and how changes are reviewed. Before any migration, export or document every record. A missing mail or verification record can break something that appears unrelated to the website.
How to explain it: “DNS is the directory that tells the internet where each part of your domain lives.”
Ownership and exit check: Can the team see a complete record set and move it without interrupting the website or email?

CDN, edge, and TLS

Delivery, protection, and encryption

A content delivery network stores copies of files closer to visitors so pages load faster. Edge services can also filter malicious traffic, redirect requests, resize images, or run code. TLS certificates create the encrypted HTTPS connection visitors expect.

Decisions to make: Decide what may be cached, where traffic and logs may travel, how certificates renew, and which security rules are active. These services can improve resilience, but complex edge rules are easy to forget during a migration.
How to explain it: “This layer helps the site arrive quickly and securely, often before a request reaches the main host.”
Ownership and exit check: Are redirects, firewall rules, certificate settings, and caching behavior documented well enough to reproduce elsewhere?

Hosting and runtime

Where the website operates

The host provides the computing environment that responds when someone requests a page. Depending on the site, it may serve static files, run application code, schedule background work, store temporary data, or connect to databases and other services.

Decisions to make: Evaluate reliability, geographic regions, scaling behavior, backups, support, deployment workflow, and cost under realistic traffic. Managed hosting removes operational work; flexible cloud infrastructure creates more choices and more responsibility.
How to explain it: “Hosting is the place where the working website runs. The domain simply directs visitors there.”
Ownership and exit check: Do the code, configuration, and data have a documented path to another compatible environment?

Layers 6–9 Experience, content, and data

The systems that shape
what the website can do.

These choices affect the editing experience, development process, privacy obligations, integrations, and the cost of change over time.

Platform or framework

How the site is constructed

A platform or framework shapes how pages are assembled, styled, tested, extended, and deployed. A hosted platform may combine templates, editing, commerce, and hosting. A code framework provides building blocks while leaving more architectural choices to the team.

Decisions to make: Match flexibility to the actual work. Consider the design system, accessibility requirements, integrations, developer availability, release process, and expected lifespan. Customization is valuable only when the team can maintain what it creates.
How to explain it: “This is the construction system. It determines what is easy to change, what requires specialist help, and what can move elsewhere.”
Ownership and exit check: Which parts are standard code or data, and which exist only inside the vendor’s system?

Content management system

How people manage content

A CMS gives editors a structured place to create, review, organize, and publish content. Some systems generate the whole website; others provide content through an API to many channels. The most important design work is often the content model, not the editing screen.

Decisions to make: Start with the people doing the publishing. Define content types, relationships, permissions, approval steps, previews, localization, and accessibility guidance. A good CMS reduces repeated formatting decisions without making ordinary updates dependent on developers.
How to explain it: “The CMS is the editorial workspace. It should reflect how your team thinks about content, not how a template happens to store pages.”
Ownership and exit check: Can the organization export clean text, metadata, relationships, media references, and redirect information?

Data and media

The records the site depends on

Databases store structured application information such as accounts, products, submissions, and transactions. Media storage holds images, video, documents, and other files. These systems may contain the most valuable or sensitive material in the entire stack.

Decisions to make: Define who may access data, where it is stored, how long it is retained, how it is backed up, and how deletion requests are handled. Separate a backup from a tested recovery process: having a file is not the same as knowing it can restore the service.
How to explain it: “This is the website’s working memory and file cabinet. Ownership, privacy, and recoverability matter more than the brand name on the service.”
Ownership and exit check: Can the client obtain a complete, documented, usable copy—and has anyone tested restoring it?

Services and measurement

The systems connected around the site

Most websites depend on third parties for forms, payments, email delivery, search, maps, scheduling, analytics, consent, automation, and monitoring. Each connection exchanges data and creates a failure mode, a recurring cost, and an account that someone must own.

Decisions to make: Inventory every dependency and the data it receives. Identify which services are essential, what happens during an outage, how pricing changes with use, and whether the site can degrade gracefully instead of failing completely.
How to explain it: “These are the utilities connected to the website. They extend what it can do, but each one needs an owner and a backup plan.”
Ownership and exit check: If a service disappeared tomorrow, what would stop working, what data would be lost, and what alternative is available?

Choosing a stack Begin with the work

Describe the constraints
before comparing tools.

A stack should follow from the organization’s publishing needs, visitor experience, risk, team capacity, and expected lifespan. Product names come later.

Six areas to understand

1
Content operationsHow much will be published, how often, by whom, and through which approval steps?
2
Visitor experienceIs this primarily information, or does it require accounts, transactions, search, and custom workflows?
3
Audience and accessWhere are visitors, what devices do they use, and what accessibility and performance needs must be met?
4
Risk and responsibilityWhat personal, financial, health, or regulated data passes through the system?
5
Operating capacityWho will update, secure, monitor, and troubleshoot the site after launch?
6
Expected life and exitHow long should the site last, and which assets must survive the next platform or team?

Common project shapes

Choose the least complicated system that still respects the risk.

These patterns are starting points rather than vendor recommendations.

An early idea or small service

The offer is still changing and the team is small.

Approach: A hosted platform with built-in editing and managed services usually reduces setup and maintenance.
Retain: Keep the domain, source content, customer list, and analytics in organization-controlled accounts.
Be careful of: Avoid building complex workflows before repeated use proves they are necessary.

A content-led organization

Many editors publish substantial content across channels.

Approach: A structured CMS, flexible presentation layer, and managed hosting can support reuse and governance.
Retain: Preserve the content model, media, redirects, search information, permissions, and editorial documentation.
Be careful of: Do not optimize the CMS for developers while making daily publishing difficult.

A digital product

The website includes accounts, transactions, workflows, or proprietary logic.

Approach: An application framework, database, APIs, and observable cloud runtime provide appropriate control.
Retain: Own the code, schemas, data, infrastructure map, deployment process, and operational history.
Be careful of: Product architecture needs testing, security, monitoring, and maintenance beyond a marketing site.

A time-bound campaign

The project has a hard launch date, focused action, and planned end.

Approach: A lightweight builder or static site with minimal integrations keeps delivery and archival simple.
Retain: Keep leads, results, consent records, final files, and any redirects that must continue afterward.
Be careful of: Plan the shutdown before launch so a six-week campaign does not create years of subscriptions.

A useful client explanation

Explain the system, not just the recommendation.

“Your website is a set of connected systems. We will choose which should be simple, which need flexibility, and which your organization should control directly. For each one, I will show you who owns the account, what it costs, who maintains it, what information it holds, and how it could be replaced.”

Two questions to keep returning to: What must this website make possible now? What must this decision never take away later?

Minimum viable handoff

Domain registrar and recovery access
DNS provider and complete record export
Hosting, billing, regions, backups, and support
Code repository and deployment instructions
CMS administrators and content export procedure
Database, media, retention, and recovery process
Analytics, consent, search, and monitoring access
Third-party services, data flows, costs, and renewals
Licenses, certificates, security contacts, and incident plan
Named maintenance owner and review schedule