Connect hosting, domains, and caches to production

Match hosting and the runtime to how data changes

Even correct server code cannot deliver new information if a crawler cannot connect to the domain or receives an old draft from the CDN. Search and AI process the responses received at actual URLs. Hosting, domain, and cache settings help those URLs keep delivering the current public documents.

Hosting is a service that runs and serves files or applications for use on the internet. Static hosting serves files prepared in advance. Node.js is an environment for running JavaScript on a server. Reading a database and generating HTML for every request requires a server runtime or managed platform that supports those functions.

Serverless functions run code when requests arrive while the platform manages the servers. Containers package code with the files needed to run it. A VM, or virtual machine, lets you manage the operating system and server yourself. With any approach, check limits on execution time, memory, concurrent requests, and database connections.

A cold start delays the first request while a new execution environment is prepared. A region is the area where servers are located. A large distance between server and database can increase query round-trip time. Record HTML generation time and database query time separately, then adjust the execution region, connection reuse, and caching.

When operating several servers, configure them to read the same public content and cache-update state. Different caches on each server's local disk can make the same URL return different articles on successive requests. Align cache sharing and revalidation across instances with the Next.js self-hosting guide and the deployment platform's capabilities. An instance is one running server program.

Connect the production domain through DNS and HTTPS

DNS, the Domain Name System, resolves a domain name to a connection address. An A record links an IPv4 address, AAAA an IPv6 address, and CNAME another hostname. TXT holds text values used for purposes such as ownership verification. Configure the records required by the hosting service in your DNS provider's dashboard. Providers differ in how they offer CNAME-like connections at a domain's root. See the explanation of domains and DNS.

TTL, or Time To Live, specifies how long a DNS response may be reused. After an address changes, clients that cached the old record may connect to the old server until its TTL expires. Prepare the new server to accept the canonical domain before switching. After switching, check that both old and new connections serve the intended page. If an AAAA record is registered, check the IPv6 path too.

HTTPS is HTTP protected by TLS, Transport Layer Security. A certificate is used to verify the identity of the domain you connect to. Check that the certificate covers the production domain and actual connection names such as www, and that validity and automatic renewal are in order. Certificate errors can cause browsers or crawlers to stop the connection before receiving content. The TLS explanation describes connection protection and the role of certificates.

Choose an HTTPS canonical URL and permanently redirect HTTP and www variants to it. DNS specifies which server to connect to; an HTTP redirect specifies the URL visitors should move to. Check hosting-domain settings and redirects separately. Use HTTPS for image, CSS, and script URLs too, reducing mixed-content problems caused by loading HTTP resources within a secure connection.

Let public documents through the CDN, proxy, and WAF

A reverse proxy receives requests in front of a server and forwards them to an internal server. A load balancer distributes requests among multiple servers. A CDN edge handles requests near users. A platform may combine these roles, so begin by drawing the services through which current requests pass.

A WAF, or Web Application Firewall, inspects HTTP requests and blocks those it identifies as attacks. A rate limit caps requests over a given period. A bot challenge asks for a human click or browser-code execution. If it appears before a public article, a crawler may receive verification instructions instead of the article.

Find blocked paths, times, rules, and status codes in CDN and WAF request logs. Adjust the relevant rules so public articles, robots.txt, sitemaps, and required images are delivered normally. Keep authentication for administrative pages and drafts, and keep attack blocking. When allowing search bots, use the operator's published IP ranges or verification method rather than trusting the name string alone.

Google requests can be checked against official IP lists, or by finding the hostname through reverse DNS and confirming that forward DNS resolves to the original IP. Google's crawler verification guide explains verification by bot type. User-Agent is an identification string supplied by the requesting program, so another program can send the same name.

When using host and protocol information forwarded by proxies, accept values only from trusted proxies. Build canonical URLs from the confirmed production-domain setting. Also check whether the CDN or proxy changes error responses to 200 or sends all nonexistent paths to the homepage. If origin and frontend responses differ, compare which stage changed the status code, headers, or body.

For example, a browser may open an article after a confirmation button is clicked while an automated crawl request receives only that confirmation screen. In that case, even content generated by SSR does not reach the crawler. Comparing the origin's 200 response with a CDN's 403 or challenge HTML distinguishes a content-generation problem from an access block.

Return accurate status codes for documents, moves, and errors

Status codes report the result of an HTTP request as three digits. A normal article returns 200 with its body, a permanent move 301 or 308, and a missing document 404. A 410 means the resource is permanently gone. Choose according to the service's deletion policy and framework support.

A soft 404 returns status 200 but looks like an empty document or an error message. Replacing an unknown slug with the homepage or handling a database error as an empty article can cause it. Distinguish a genuinely missing document from a temporary query failure in the response. Google's treatment of status codes explains each code's effect on crawling.

Report temporary server failures with 5xx codes and repair the cause. Request limits can use 429; temporary service interruptions can use 503 where appropriate. Retry-After indicates how long to wait or when to retry. Repeated limits can reduce normal crawling too, so check error rates and capacity together.

Define cache locations and update conditions

Caches can exist in browsers, CDNs, application data queries, and generated pages. A cache key identifies a stored result. If responses vary by language, user, or query as well as URL, include those differences in the key or avoid shared storage. Cache-Control governs HTTP caching; framework-internal data caches are updated through separate settings.

max-age is the period in seconds during which a response can be reused as fresh. s-maxage applies that period to shared caches such as CDNs. private allows storage only in user-specific caches; no-store prohibits storing the response. no-cache permits storage but requires validation with the server before reuse. Similar names have different behavior, so select response headers using the HTTP caching explanation.

ETag is a validator identifying a response version; Last-Modified is its modification time. If a conditional request using stored values finds unchanged content, the server can return 304. Vary tells caches which request headers affect the response. Arbitrarily removing Vary values required by the platform can mix responses for different requests. See the HTTP caching standard for validation and storage conditions.

stale-while-revalidate permits serving an old response within a defined window while updating it in the background. immutable is for resources whose content will not change during their freshness period. Long caching can suit public CSS and JavaScript whose filenames contain a content hash. For articles or photos that may need correction or withdrawal, first define acceptable persistence and an invalidation method.

Revalidation checks whether stored content remains valid or produces a new result. Invalidation and purging prevent further use of an old cache entry. After CMS publication, update data and page caches for the detail page, listing, and sitemap. If an external CDN caches separately, connect its update as well. Apply the Next.js caching guide for the installed version.

For material that must become inaccessible immediately after withdrawal, design requests to pass through a publication-status check even if cached copies remain. A server cannot reclaim files already downloaded by a browser. Define what the server and CDN return to new requests and when blocking takes effect, then check across regions, first requests, and repeat requests.

If closing time changes from 17:00 to 16:00 but the CDN returns old HTML, crawlers visiting after the change still read 17:00. Merely changing the site's dateModified to today may leave the delivered fact unchanged. That is why caches are updated after saving and the hours and revision in actual responses are checked. Then compare the external search system's latest crawl time with the source text it cites.

Align environment variables, deployment, and logs with the production URL

Environment variables inject settings from outside the code. Separate production domains, database connection addresses, storage keys, and other settings for development, preview, and production. Next.js values prefixed with NEXT_PUBLIC_ may be included in browser code and are fixed at build time. Keep secrets in server-only settings. Settings that generate public URLs must match the production domain.

CI, Continuous Integration, automatically runs checks and builds when changes are integrated. CD, Continuous Delivery or Deployment, prepares the result for deployment or deploys it. An artifact is a deployable file produced by a build. Use a version identifier to establish that the tested output and the deployed output are the same.

Preview and staging are environments for checking changes before production. Define their access to production data and secrets, and restrict access through authentication. Check that their search-exclusion settings are not copied to production. After changing the production-domain connection, request the body, headers, and assets again through that domain.

Logs record requests and processing results. Record status codes, paths, processing times, response sizes, and deployment versions. Use request IDs to connect CDN, application, and database processing. A timeout stops work that has not completed within the allotted time. If content generation is slow, examine database queries, external APIs, and image-processing time separately.

Monitoring continuously observes error rates, latency, and other signals. Alerts notify the responsible person when defined conditions are met. Watch for rising 5xx rates on normally public articles, certificate expiry, and failed cache updates after publication. Identify the previous deployment and database backup to use during an incident, then check actual public URLs again after recovery.

Separate caches for public documents and user-specific responses

Shared caching can be used when everyone receives the same response and some delay is acceptable. For responses that vary by login state or material requiring immediate withdrawal, avoid shared storage or check authorization before returning it. When frontend infrastructure overwrites framework-generated headers, review the resulting behavior too.

For example, Cache-Control: private, no-store can prevent storage of a user's private material. Public assets whose URLs change with their content can use a long max-age and immutable. Choose public HTML cache duration after defining acceptable update delay and invalidation options. Changing HTTP headers does not automatically update an internal database-query cache.

Update caches after publication finishes

The exercise's current-article route uses force-dynamic to render on every request. When caching CMS queries or operating static or ISR routes, call revalidation after the save completes. The following function is used in server-side publishing after authentication and authorization checks.

// lib/refresh-guide.ts — cacheComponents: false configuration import { revalidatePath } from 'next/cache' export function refreshGuide(slug: string) { if (!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(slug)) { throw new Error('Invalid slug') } revalidatePath(`/guides/${slug}`) revalidatePath('/') revalidatePath('/sitemap.xml') } // Order: check user permissions → finish saving publication to the database → refreshGuide(slug)

revalidatePath requests revalidation of a path. Depending on where it is called and the cache configuration, the update may occur on the next visit. A separate CDN uses its platform's invalidation mechanism. If several pages read data with the same tag, consider tag-based updates as well. Compare the revalidatePath guide with the actual first repeat request to check its effect.

With Cache Components enabled, choose lifetimes and call locations for cacheLife, cacheTag, revalidateTag, and updateTag separately. Revalidation that serves stale content first behaves differently from immediate expiry. On withdrawal, also check whether a CDN returns the old document before the request reaches the origin. Read the revalidation guide for the cache model in use.

Call this function in the server-side publication handler after the database save completes. It validates the slug, then updates caches for the detail page, homepage, and sitemap. Calling it before saving can cache content that has not yet changed. If a request after saving still shows the old revision, check Next.js caching and the external CDN separately. In a database-backed service, request the detail page, listing, and sitemap after publication or withdrawal and compare their public status and content.

Revalidating only the detail page can leave an old summary on the homepage or an old date in the sitemap. refreshGuide targets the detail page, homepage, and sitemap together to update the public outputs affected by one publication. Add further routes to this update relationship when they gain relevant data or caches.

Distinguish cache failures by comparing source and public responses

The public-data exercise compares source and cache reads at the same time in its second test. If the source says 10–16 and the cache says 10–17, saving succeeded but delivery was not updated. Invalidate the failed path's cache instead of asking the editor to save the article again.

Even if the detail page returns 404 after withdrawal, the article may remain in cached listings and sitemaps. Clear the memory cache with clearCache. When also using a CDN, record the document ID, revision, and paths to update in the publication job, and call the CDN's invalidation API. Retry failed requests. Check that CDN URLs also return 404 or deny access immediately after withdrawal.

Read HTTP no-store alongside server-side image reuse

Transforming an image on every request repeatedly decodes and encodes the same source. Storing transformed results inside the server reduces that cost. no-store in an HTTP response tells receiving caches not to store the response. A server reusing the same derivative file in its own private storage uses a different storage location and access path. Cache-Control

In the image exercise, requesting /media/photo?w=640 twice produces two responses with private, no-store, max-age=0. The server's transforms value is 1. The second request receives image bytes too, but the server does not transform the image again. Reduced transfer size comes from sending a small WebP; reduced server work comes from reusing the transformed result.

Withdrawable material needs a request path that checks current publication status every time. Files already stored on a public CDN can be delivered without the origin's publication check. By contrast, long caching can reduce transfer for permanently public assets such as a logo with a content-hashed URL. Define change and withdrawal requirements before choosing response caching and storage.

setPublished in the exercise store changes in-process state. In a database-backed environment, check that new requests read the new state after the publication transaction completes. If an external CDN is added, request both source and derivative URLs through it after withdrawal to check remaining files and invalidation results.