A page can fail before the browser receives any HTML. It can also receive the HTML successfully and then fail to load the files needed to display it. Those are different problems, and they need different checks.
For technical SEO, understanding the request helps you identify which part of the system is responsible. A DNS failure belongs to a different investigation from a missing stylesheet or a PHP application returning an error.
Start with the address
Suppose a visitor opens https://example.com/products/. The browser needs to connect to the host named example.com. DNS resolves that name through records that ultimately identify where a connection should go. An IP address identifies a network endpoint; the domain is the name people use to reach it.
A cached DNS result may avoid another lookup. For HTTPS, the connection also needs the appropriate secure transport setup. The browser then sends an HTTP request for the path. This is a simplified sequence: connection reuse, protocol choice, and caching can change the work needed for a particular visit.
The client in this example is the browser. The server receives the request and returns a response. A crawler is another kind of client, with different capabilities and reasons for requesting the page.
The response may come from a CDN
A content delivery network can sit between the visitor and the origin server. The CDN may return a cached response, forward a request to the origin, or apply security rules before allowing it through.
The origin is where the underlying website application or files are served. It does not have to be one physical machine. A load balancer can distribute requests between multiple application servers, while a database runs elsewhere. A smaller site may put these components on the same server.
Browser → DNS lookup → CDN or origin → HTTP response
↓
Application → database, if needed
Where WordPress and the database fit
On a typical uncached WordPress request, PHP runs the application, reads the required information from the database, applies the theme, and produces HTML. That HTML is what the browser receives. The visitor does not receive the PHP source code or direct access to the database.
A full-page cache may return saved HTML without repeating all that application work. Object caching and database caching can reduce other parts of the processing. These caches solve different problems, so clearing one does not necessarily clear the others.
Requests cost resources. Expensive database queries, slow external services, or too many simultaneous requests can increase response times. If the server stops answering, visitors and crawlers can both be affected. Adding a load balancer alone does not fix a slow shared database.
HTML starts another set of requests
The HTML may refer to CSS, JavaScript, images, and fonts. The browser requests those resources as it discovers that it needs them. Some come from the website’s own host; others may come from third parties.
These requests can succeed or fail independently. A page might return a 404 while its logo and stylesheet return 200. Conversely, a successful document can contain an image URL that no longer exists.
Turn the request flow into a diagnosis
Open Chrome DevTools Network, reload the page, and identify the main document. Check its status, response headers, and timing. Then investigate missing supporting resources individually.
If the page is slow before the HTML arrives, investigate the connection, cache, application, and server response. If the HTML arrives quickly but the page remains blank, continue with resource loading and rendering. This distinction helps a technical SEO audit reach a reproducible finding.
For a site with recurring availability or rendering problems, my technical SEO consulting service covers the investigation and the requirements developers need to address it. The next useful check is whether the content is present in the response or depends on HTML, CSS, and JavaScript working together.