START WITH THE MODEL
A website is not one thing. It is a chain of systems.
A common beginner mistake is to treat “the website” as a single object. In reality, a working page is the result of several independent systems cooperating. Your domain can be registered correctly while DNS is wrong. DNS can be correct while the web server is down. The server can respond while WordPress fails. WordPress can generate perfect HTML while a browser-side JavaScript error breaks the interface.
The professional way to think about a website is as a request path. A visitor asks for a resource. The network finds the right destination. The server or an intermediary generates or retrieves a response. The browser then interprets the returned resources and renders the page.
When something breaks, do not start by changing random plugins, DNS records or cache settings. First identify which layer is failing. Correct diagnosis is usually faster than trial and error.
THE COMPLETE REQUEST JOURNEY
What happens when a visitor types your domain and presses Enter?
The exact path can vary because browsers, operating systems, DNS resolvers, reverse proxies, CDNs and caches may already know part of the answer. But the following sequence gives you the right model.
The browser interprets the URL
The browser separates the scheme such as https, the hostname such as affiliatebest.site, the path such as /website-building/, and any query string or fragment. It now knows what host it needs to reach and what resource it will request.
The hostname is resolved
If the necessary address is not already cached, the system asks DNS how the hostname should be reached. DNS commonly returns an IPv4 address through an A record or an IPv6 address through an AAAA record. A CNAME may point one hostname to another hostname. In modern hosting, the returned address may belong to a CDN, reverse proxy or load balancer rather than the physical origin server.
A network connection is established
The browser connects to the destination. For HTTPS, a secure TLS session must be established before protected HTTP data is exchanged. Depending on the HTTP version, transport details differ: HTTP/1.1 and HTTP/2 commonly use TCP, while HTTP/3 uses QUIC over UDP.
The browser sends an HTTP request
A typical navigation request asks for a resource with GET. The request also carries headers that describe things such as the intended host, accepted content types, cookies and caching information. The server or edge system uses this information to decide how to answer.
The infrastructure decides where the request goes
A CDN, web application firewall, reverse proxy or load balancer may answer directly, reject the request, redirect it, or forward it to the origin server. This is why “the server” is often not a single machine on modern sites.
The application produces or retrieves the response
For a static file, the web server may simply return the file. For a dynamic WordPress request, PHP and WordPress may run, read settings and content from the database, execute theme and plugin logic, and generate HTML.
The server returns an HTTP response
The response contains a status code, headers and usually a body. A successful HTML document normally returns a 2xx status. Redirects use 3xx codes. Client-facing problems often appear as 4xx. Server-side failures often appear as 5xx.
The browser parses the response and requests dependencies
The initial HTML references CSS, JavaScript, images, fonts and other resources. The browser requests what it needs, builds its internal document and style structures, executes scripts where applicable, lays out the page and paints pixels to the screen.
If a domain does not resolve, editing WordPress cannot fix it. If DNS resolves but HTTPS fails, changing article content cannot fix it. If the server returns valid HTML but a button is broken, the problem may be in front-end JavaScript. Each symptom narrows the search.
IDENTITY VS LOCATION
Domain names and URLs are related, but they are not the same thing.
A domain name is a human-readable name in the Domain Name System, such as affiliatebest.site. A URL is an address for a specific resource and can include the protocol, hostname, path, query parameters and a fragment.
https://www.example.com/guides/seo/?level=beginner#technical
Understand the domain hierarchy
In www.example.com, .com is the top-level domain, example is the registered second-level name, and www is a subdomain/hostname label. Different subdomains can point to different services or infrastructure.
Registration does not equal hosting
Buying a domain gives you control over a name for a registration period. It does not automatically mean your website files exist, WordPress is installed, email is configured or DNS points to the correct hosting provider. The registrar and hosting provider can be the same company, but conceptually they are separate roles.
The human-readable name users remember.
The distributed system that tells clients how hostnames map to services and addresses.
The compute, storage and network environment that serves the site.
The full address of a particular resource.
HOW THE NAME FINDS THE DESTINATION
DNS translates names into information computers can use.
ICANN describes DNS as the system that lets people use memorable domain names instead of directly using IP addresses. The simplified explanation is “domain → IP,” but professional DNS work is broader than that: DNS records can route websites, email and service-verification information, and they are distributed across authoritative nameservers and recursive resolvers.
The records you will encounter most often
| Record | Purpose | Typical website use |
|---|---|---|
| A | Maps a hostname to an IPv4 address. | Point the root domain or hostname to an IPv4 endpoint. |
| AAAA | Maps a hostname to an IPv6 address. | Provide IPv6 reachability. |
| CNAME | Makes one hostname an alias of another hostname. | Common for www or third-party services. |
| MX | Specifies mail servers for a domain. | Route incoming email; not a web-page record. |
| TXT | Stores text used by many verification/security mechanisms. | Domain verification, SPF-related data and service ownership checks. |
| NS | Identifies authoritative nameservers. | Delegates DNS authority for the domain/zone. |
Why DNS changes are not always instant
DNS information is cached at multiple levels. Records have a TTL (time to live), and previously cached answers can continue to be used until they expire. “Propagation” is therefore not one global switch. Different resolvers may refresh at different times, which is why one network can see the new destination before another.
An IP address is not always your origin server
If you use a reverse proxy or CDN such as Cloudflare, DNS may return an edge address. The edge receives the browser request and then communicates with your origin when needed. This is normal and can improve performance, security and availability, but it changes how you diagnose problems because there is now an additional layer between visitor and origin.
A DNS mistake can take the website, email or verification records offline. Before changing a record, record its current value, understand its purpose, and know how you will verify the new state.
WHERE THE APPLICATION RUNS
Hosting is a service. A server is part of the infrastructure that provides it.
“Hosting” is the commercial and operational service that gives your website computing resources, storage and network connectivity. A server is a physical or virtual system that runs software to answer requests. With managed or shared hosting, you usually do not administer the full server stack yourself.
A typical WordPress stack contains several layers
Storage, memory and CPU solve different problems
Storage holds files and persistent data. Memory (RAM) is working space used by running processes and caches. CPU executes instructions. Network throughput affects how quickly data can be transferred. A plan with large storage is not automatically fast; performance depends on the workload and the bottleneck.
Shared, managed, cloud and VPS hosting are operating models, not quality guarantees
Shared hosting reduces cost by sharing infrastructure. Managed WordPress hosting offloads more operations to the provider. A VPS gives more isolated control but also more responsibility. “Cloud” can describe many architectures and should not be treated as a guarantee of speed or reliability. Evaluate resource limits, isolation, backups, support, data-center locations, security controls and scalability rather than the label alone.
WordPress.org currently recommends PHP 8.3+, MySQL 8.0+ or MariaDB 10.11+, and HTTPS support. WordPress can run on older versions, but the official requirements page warns that legacy versions may be end-of-life and expose security risk. Always check the current official requirements before choosing hosting.
THE WEB'S REQUEST / RESPONSE LANGUAGE
HTTP is the protocol used to request and return web resources.
MDN defines HTTP as an application-layer protocol and describes the Web as a client-server system: the client, usually a browser, sends a request and the server sends a response. A page can require many HTTP exchanges because HTML, CSS, JavaScript, images, fonts and API data may all be separate resources.
A simplified request
GET /website-building/ HTTP/2
Host: affiliatebest.site
Accept: text/htmlA simplified response
HTTP/2 200
Content-Type: text/html; charset=UTF-8
Cache-Control: ...
<!doctype html>
<html>...</html>Status codes are diagnostic signals
The request was accepted and processed successfully.
The client is told to use another URL or cached condition.
Examples include 403 Forbidden, 404 Not Found and 429 Too Many Requests.
The server or upstream application failed to complete a valid request.
HTTP is stateless at its core
Each request is conceptually independent. Websites build sessions and personalized behavior on top of HTTP using mechanisms such as cookies, tokens, application state and server-side storage. This matters when diagnosing login, cart or personalization problems: a page can load normally while session state is broken.
Headers can change behavior without changing visible HTML
HTTP headers control caching, content type, redirects, cookies, security policies and other behavior. A professional audit therefore looks beyond “does the page visually load?” and checks the actual network response.
SECURE TRANSPORT
HTTPS is HTTP protected by TLS.
TLS provides confidentiality, integrity and server authentication for data in transit. In practical terms, it helps prevent third parties on the network from reading or silently modifying traffic between the browser and the server. Modern websites should serve pages and subresources over HTTPS.
What the certificate actually does
A website certificate binds a public key to a domain identity through a trusted Certificate Authority process. During the TLS handshake, the browser validates the certificate chain and hostname before establishing protected communication. Services such as Let’s Encrypt automate domain validation and certificate issuance using ACME.
“SSL certificate” is common terminology, but TLS is the modern protocol
SSL is the predecessor of TLS. Hosting dashboards and marketing pages still often say “SSL certificate,” but modern HTTPS uses TLS. For a site owner, the practical goal is a valid certificate, correct HTTPS configuration, automatic renewal and no insecure subresources.
Mixed content is a real deployment defect
If the HTML document loads over HTTPS but scripts, styles or images are requested over insecure HTTP, browsers can block or downgrade those resources. After moving a site to HTTPS, verify that internal URLs, assets, redirects and canonical URLs consistently use HTTPS.
HSTS tells browsers to use HTTPS for a domain for a defined period. It improves downgrade protection, but enabling includeSubDomains or preload before every relevant subdomain supports HTTPS can make those subdomains unreachable. Test the HTTPS estate first; do not copy security headers blindly.
FROM RESPONSE TO PIXELS
The server does not send you a screenshot. The browser constructs the page.
The initial HTML document describes structure and references other resources. The browser parses the HTML into a document model, parses CSS into styling rules, resolves layout, paints visual elements and executes JavaScript where required. Modern browsers perform many optimizations, but the important concept is that rendering is a client-side process built from resources returned over the network.
Defines semantic structure and content: headings, paragraphs, links, forms, images and regions.
Controls presentation: layout, typography, spacing, responsive behavior and visual states.
Adds behavior: interactions, state changes, dynamic requests and application logic in the browser.
One visible page can involve dozens or hundreds of requests
A page may load fonts from one host, analytics from another, images from a CDN, scripts from the site and API data after the initial render. This means page performance and reliability are affected by every critical dependency, not just the HTML response.
Browser Developer Tools are part of professional website work
The Network panel shows requests, status codes, timings, transferred sizes and response headers. The Console exposes JavaScript errors and warnings. The Elements/Inspector panel shows the rendered document and active CSS. Learning these tools reduces guesswork dramatically.
DYNAMIC WEBSITE GENERATION
WordPress usually generates HTML dynamically from code, configuration and database content.
WordPress is a content management system written primarily in PHP. Its posts, pages, settings and other structured data are stored in a database, while themes, plugins, uploaded media and WordPress core files live in the filesystem. When a non-cached request reaches WordPress, multiple layers cooperate to generate the response.
It decides whether to serve a static file or route the request into WordPress/PHP.
WordPress loads configuration, core code and the active site environment.
Routing and query logic determine whether the visitor requested a page, post, archive, search result or another route.
Plugins can alter behavior and data. The active theme controls presentation templates and front-end assets.
Content, metadata, settings, users, taxonomy and plugin data may be read or updated.
The final response is sent back through the web stack unless a cache or edge layer has already answered.
Theme, plugin and content are different responsibilities
A theme should primarily control presentation. A plugin adds or changes functionality. Content belongs in posts, pages and structured data. Mixing all three without boundaries makes updates risky. This is why AffiliateBest is being built with a theme for design and separate modules/plugins for larger business functions.
The database is not a folder of pages
WordPress pages are database records rendered through templates. Editing a PHP template changes how matching content is presented; editing a page changes stored content. Understanding the distinction prevents destructive edits and helps you choose the right extension point.
A full-page cache may return previously generated HTML without running the complete PHP/WordPress/database path for every visitor. That is one reason caching can dramatically reduce server work — but it also means changes can appear “stuck” until the relevant cache is purged or expires.
PERFORMANCE LAYERS
Caching stores reusable results. A CDN moves content closer to users and can add an edge layer.
Performance work becomes confusing when every optimization is called “cache.” There are several distinct caches, and clearing the wrong one may do nothing.
| Layer | What it can cache | Typical symptom when stale |
|---|---|---|
| Browser cache | CSS, JS, images and other resources on the visitor device. | One browser sees old assets while another sees the update. |
| Page cache | Generated HTML responses. | WordPress content or layout changes are not reflected. |
| Object cache | Reusable application/database results. | Application data appears stale or DB work remains high if misconfigured. |
| CDN / edge cache | Static assets and sometimes HTML/API responses. | Visitors in some regions receive an older version. |
| DNS cache | DNS answers. | A changed DNS record is visible to some resolvers but not others yet. |
A CDN is not just “faster images”
A content delivery network can serve cached content from geographically distributed edge locations. Depending on the provider and configuration, the CDN may also provide TLS termination, DNS, DDoS mitigation, a web application firewall, bot controls, image optimization and reverse proxying. Treat it as infrastructure, not merely a WordPress plugin.
Cache invalidation is part of deployment
If you update CSS, JavaScript, HTML or images, your deployment process must ensure users receive the new versions. Versioned asset URLs, appropriate cache headers and targeted purges are safer than teaching yourself to “clear everything” after every change.
FAILURE-FIRST THINKING
Learn to map symptoms to layers before you attempt a fix.
Domain does not resolve
Likely layer: registration, nameservers or DNS. Check domain status and authoritative DNS before touching WordPress.
Certificate warning
Likely layer: TLS/certificate/hostname configuration. Check validity, hostname coverage, renewal and proxy/origin configuration.
Too many redirects
Likely layer: HTTP redirect logic, proxy HTTPS settings, WordPress URL configuration or conflicting rules.
500 / critical error
Likely layer: server or application. Inspect server/PHP/WordPress logs and the last known change instead of editing DNS.
Page loads but looks broken
Likely layer: CSS/JS/assets/cache. Inspect Network and Console for missing or blocked resources and front-end errors.
Only old version is visible
Likely layer: browser, page, object or CDN cache. Identify which response is stale before purging everything.
Admin works, public site does not
Likely layer: front-end template, page cache, proxy/CDN rule, permissions or route-specific application failure.
Site works on Wi‑Fi but not mobile data
Likely layer: DNS cache, IPv4/IPv6 difference, routing, firewall or regional edge issue. Compare network resolution and responses.
PROFESSIONAL WORKFLOW
Diagnose from the outside inward.
When a production site fails, the fastest safe sequence is usually to verify each layer without making changes until you know where the failure begins.
- Confirm scope.Is the entire domain down, one URL broken, one user affected, one browser affected, or only the admin area failing?
- Check DNS.Does the expected hostname resolve? Are you testing the correct A/AAAA/CNAME result and authoritative nameservers?
- Check the HTTPS connection.Does the certificate match the hostname and validate without browser warnings?
- Inspect the HTTP response.What status code and headers are returned? Is there a redirect chain? Is a CDN or proxy answering?
- Separate origin from edge.If a CDN or reverse proxy exists, determine whether the problem is at the edge or the origin before bypassing controls.
- Inspect application health.For WordPress, look at Site Health, PHP/server logs, plugin/theme changes, database availability and resource limits.
- Inspect browser-side behavior.Use Network and Console to find failed assets, blocked mixed content, CORS problems or JavaScript errors.
- Check caches last, but deliberately.Identify which cache can contain the stale response and purge only what is necessary.
- Verify the fix from more than one path.Test the affected URL, logged-out state, mobile/desktop where relevant, and an external network if the issue may be DNS or edge related.
- Document the cause.Record what failed, why, what changed and how to prevent recurrence. Repeated incidents should become monitoring or automation work.
If you update DNS, disable plugins, purge every cache and change PHP version simultaneously, a recovered site tells you almost nothing about the root cause. Controlled changes preserve evidence.
FOUNDATION CHECKLIST
Before you move to website planning and hosting decisions, verify that these concepts are clear.
PRACTICE
Do these exercises on a real site. Reading alone is not enough.
Trace one URL from name to page
Choose a page on your website. Write down its scheme, hostname and path. Identify the domain registrar, authoritative DNS provider, web host and whether a CDN/reverse proxy exists. Your goal is to map ownership and responsibility, not just list brand names.
Inspect DNS without changing it
Use a DNS lookup tool or nslookup/dig to inspect the hostname. Identify A, AAAA or CNAME behavior. Then inspect the authoritative nameservers. Do not modify any record during this exercise.
Read the browser Network panel
Open Developer Tools → Network and reload the page. Find the main document request. Note the status, protocol, transfer size and response headers. Then identify at least one CSS, JavaScript and image request.
Inspect HTTPS
Open the browser's site/certificate information. Confirm that the certificate is valid for the hostname. Then check the page Network/Console views for insecure or blocked mixed-content requests.
Explain WordPress in your own words
Without looking back at this guide, explain what happens after a request reaches a WordPress origin when there is no full-page cache. If you cannot clearly place the web server, PHP, WordPress, theme, plugins and database in the sequence, review the WordPress flow section.
REFERENCE
Core terminology you should know before the next module.
- Browser
- Client software that requests web resources and renders/interacts with them.
- Domain name
- A human-readable name within DNS, such as
example.com. - DNS
- The distributed Domain Name System used to resolve names and publish service-related records.
- IP address
- A network-layer address used to route traffic to an endpoint.
- URL
- The complete address of a resource, including a scheme and location and optionally a path, query and fragment.
- Hosting
- A service that provides infrastructure and operational resources for a website/application.
- Origin server
- The backend server or application infrastructure where original content is served/generated before optional edge layers.
- HTTP
- The application protocol used for web request/response communication.
- HTTPS
- HTTP carried over a TLS-protected connection.
- TLS
- The security protocol that provides encryption, integrity and authentication for the connection.
- CMS
- Content Management System — software used to create, organize and publish content; WordPress is one example.
- PHP
- A server-side programming language used extensively by WordPress.
- Database
- Structured data storage used by WordPress for content, settings, users and other application data.
- CDN
- A distributed edge network that can serve cached content closer to users and may provide additional security/performance services.
- Cache
- A stored reusable result intended to reduce repeated work or latency.
- Reverse proxy
- An intermediary that receives client requests and forwards appropriate requests to backend/origin servers.
PRIMARY & TECHNICAL SOURCES
Official English references used for this module
Web standards and hosting requirements change. These links are intentionally primary or first-party technical references so you can verify details and continue deeper study.
Source review: . Time-sensitive product, legal, analytics and platform details should still be re-checked at the source immediately before implementation.
MODULE 01 COMPLETE
Next: choose what kind of website is worth building.
Technical knowledge prevents blind setup mistakes. The next module will move from infrastructure to strategy: website idea, niche, audience problem, competition, monetization options, content depth and the business model behind the site.