A static website serves prepared HTML, CSS, JavaScript and media without requiring a server to render each response. Google Cloud Storage can hold these objects, while a backend bucket, external Application Load Balancer and Cloud CDN can distribute cacheable content nearer to users. The architecture has multiple components, so simply uploading files to a bucket does not create a fully secured, production-ready HTTPS website.
Google’s current documentation describes Cloud CDN as integrated with supported external Application Load Balancer configurations. Domain names, certificates, cache policies, origin exposure, content invalidation and observability must be designed explicitly. A reader should understand which component owns each part of the request path before following any step-by-step console example.
Prepare objects and a Cloud Storage bucket
Google Cloud Storage is an object storage service that allows you to store and retrieve any amount of data at any time from anywhere in the world. For static website hosting, Cloud Storage serves as the origin where your HTML, CSS, JavaScript, image, and font files live before being distributed to users. Files stored in Cloud Storage are organized into containers called buckets, and each bucket can be configured with specific access permissions, storage classes, and geographic locations that affect both performance and cost. When used for website hosting, a Cloud Storage bucket must be configured to allow public read access so that visitors can retrieve your files without authentication. You also need to set a default index page and a custom error page within the bucket configuration to ensure that users are directed to the correct files when they visit your domain or encounter a missing page. Cloud Storage supports custom domain mapping, which allows you to serve your website from your own domain name rather than the default storage URL, making it suitable for production websites with professional branding requirements.
Creating and configuring a Cloud Storage bucket for static website hosting involves several steps that must be completed in the correct order to ensure everything works properly. Start by opening the Google Cloud Console, navigating to the Cloud Storage section, and creating a new bucket with a name that matches your custom domain exactly, such as. This naming convention is required when you intend to map a custom domain to your bucket and serve your website from a recognizable web address. Once your bucket is created, upload your static website files by dragging them into the console interface or using the gsutil command-line tool for larger deployments. After uploading, configure the bucket for public access by removing the uniform bucket-level access restriction and setting the allUsers principal to have the Storage Object Viewer role. Finally, set the index page suffix to index. html and the error page to 404. html within the bucket’s website configuration settings. These steps complete the basic bucket setup and make your files accessible through a web browser using the default Cloud Storage URL.
Connect a domain and prove ownership
Connecting a custom domain to your Google Cloud Storage bucket requires verifying ownership of the domain and creating the appropriate DNS records with your domain registrar. Begin by verifying your domain through Google Search Console or Google Domains, which confirms to Google that you are the legitimate owner of the domain you intend to use. Without this verification step, you will not be able to create a bucket with a name matching your domain or map the domain to your hosting setup. After verification, log in to your domain registrar’s DNS management panel and create a CNAME record that points your www subdomain to c. This record tells the global DNS system to route traffic for your domain to Google Cloud Storage, where your website files are stored. DNS propagation can take anywhere from a few minutes to 48 hours depending on your registrar and the time-to-live settings on your existing DNS records. Once propagation is complete, visitors who type your domain into a browser will be directed to your Cloud Storage bucket and served your static website files.
Understand the Cloud CDN and backend bucket path
Google Cloud CDN, which stands for Content Delivery Network, is a globally distributed network of edge servers that caches copies of your website content at locations physically close to your users around the world. When a visitor requests a page from your website, Cloud CDN serves the content from the nearest edge location rather than retrieving it from your origin bucket in a single geographic region. This reduction in physical distance between the server and the user translates directly into lower latency, faster page load times, and a better overall browsing experience. Beyond speed improvements, Cloud CDN also reduces the load on your origin infrastructure by serving cached content for repeat requests without touching the origin bucket at all. This caching behavior lowers your egress costs from Cloud Storage and improves your website’s ability to handle sudden traffic spikes without degradation in performance. Google’s CDN infrastructure spans over 100 edge locations worldwide, ensuring that users on every continent benefit from fast content delivery regardless of where your origin bucket is physically located.
Enabling Cloud CDN for your static website on Google Cloud requires setting up a load balancer, as Cloud CDN is not applied directly to a Cloud Storage bucket but rather to a backend service or backend bucket attached to an HTTP or HTTPS load balancer. Begin by navigating to the Network Services section of the Google Cloud Console and selecting Cloud CDN, then follow the prompts to create a new CDN configuration. You will need to choose your backend type, which in this case is a backend bucket pointing to your Cloud Storage bucket containing your website files. During the setup process, enable the Cloud CDN toggle on your backend bucket configuration and select your desired cache mode, which controls how Cloud CDN determines what content to cache and for how long. The recommended cache mode for static websites is Cache-Control header based caching, where you set explicit cache duration headers on your files and Cloud CDN respects those values when deciding how long to store content at edge locations. After saving your CDN configuration, traffic routed through the load balancer will automatically be served from the nearest edge location, and your website performance will improve immediately for users around the world.
Configure HTTPS and cache behavior
Serving your static website over HTTPS is essential for security, user trust, and search engine ranking, and Google Cloud makes it straightforward to provision and manage SSL certificates for your custom domain. When you set up an HTTPS load balancer in Google Cloud, you have the option to use a Google-managed SSL certificate that is automatically provisioned and renewed without any manual intervention on your part. This removes the complexity of certificate management and eliminates the risk of your site becoming insecure due to an expired certificate. To configure HTTPS, create a new HTTPS load balancer in the Google Cloud Console and attach your backend bucket to it. During the frontend configuration step, select HTTPS as the protocol and create a new Google-managed certificate by entering your custom domain name. Google will automatically verify your domain ownership and issue the certificate within minutes to a few hours. Once the certificate is active, all traffic to your website will be encrypted in transit and your browser will display the padlock icon that users expect from a trustworthy and professional website.
Setting appropriate cache control headers on your static website files is one of the most important steps for maximizing the effectiveness of Cloud CDN and ensuring that users always receive fresh content when your site is updated. Cache control headers are HTTP response headers that tell browsers and CDN edge servers how long to store a cached copy of a file before requesting a fresh version from the origin. Getting these values right balances performance with content freshness and prevents users from seeing stale content after you push updates. For files that change rarely or never, such as versioned JavaScript bundles and hashed CSS files, set a long max-age value of one year or more to allow aggressive caching at both the browser and CDN level. For HTML files, which change more frequently and determine what JavaScript and CSS files are loaded, set a much shorter max-age or use no-cache to ensure users always get the latest version of your page structure. You can set these headers in Google Cloud Storage using the gsutil tool with the -h flag or through the Cloud Console when uploading files, and Cloud CDN will automatically respect them when serving cached responses to users.
Invalidate cached content safely
When you update your static website files and push new content to your Cloud Storage bucket, Cloud CDN edge servers will continue serving the old cached version until the cache expiry time defined in your cache control headers is reached. For urgent updates such as bug fixes, security patches, or time-sensitive content changes, you may not be able to wait for the cache to expire naturally and will need to manually invalidate the cache to force edge servers to fetch fresh content from your origin bucket immediately. Google Cloud CDN supports cache invalidation through both the Cloud Console and the gcloud command-line tool. In the Console, navigate to your CDN configuration, select the invalidation tab, and enter the URL path or path pattern you want to invalidate. Using the gcloud tool, you can run the gcloud compute url-maps invalidate-cdn-cache command followed by your load balancer name and the path to invalidate. Keep in mind that cache invalidations are not instantaneous and may take a few minutes to propagate across all edge locations, so plan your deployment process accordingly when managing time-sensitive content updates.
Load-balancer routing and monitoring
The HTTP or HTTPS load balancer that sits in front of your Cloud CDN and Cloud Storage backend is a critical component of your hosting architecture and deserves careful configuration to ensure reliable and efficient traffic handling. When creating your load balancer, choose the global external HTTP or HTTPS load balancer type, as this configuration works with Cloud CDN and routes traffic through Google’s global network backbone for optimal performance. Regional load balancers do not support Cloud CDN integration and should be avoided for this use case. Within your load balancer configuration, set up URL maps to control how different request paths are routed to your backend bucket. For a simple single-bucket static website, a default route that sends all traffic to your backend bucket is sufficient. For more complex setups with multiple content sources, you can create path-based routing rules that direct requests for different URL patterns to different backends. Also configure health checks on your backend bucket to ensure the load balancer can monitor the availability of your origin and handle any disruptions gracefully without impacting the user experience.
Monitoring the performance and health of your static website hosted on Google Cloud is essential for identifying problems quickly and ensuring that your CDN configuration is delivering the expected improvements. Google Cloud provides several monitoring tools that give you visibility into request volumes, cache hit rates, latency distributions, and error rates across your hosting infrastructure. The Cloud Monitoring service, formerly known as Stackdriver, integrates directly with Cloud CDN and Cloud Storage to provide dashboards and alerting capabilities without requiring any additional configuration. Pay particular attention to your CDN cache hit ratio, which measures the percentage of requests served directly from edge cache versus those that had to reach back to your origin bucket. A high cache hit ratio, ideally above 80 or 90 percent, indicates that your cache control headers are configured effectively and users are benefiting from fast edge delivery. If your cache hit ratio is low, review your cache control headers and CDN cache mode settings to identify why so many requests are bypassing the cache. Set up alerting policies in Cloud Monitoring to notify you immediately when error rates spike or latency exceeds acceptable thresholds.
Manage delivery costs
One of the attractive qualities of hosting a static website on Google Cloud is the low cost compared to running virtual machines or managed application servers, but understanding the billing model is important for keeping costs predictable as your traffic grows. Google Cloud Storage charges based on the amount of data stored in your bucket, the number of operations performed on your objects, and the amount of data transferred out of the storage service to the internet or to other Google Cloud services. For most small to medium static websites, these charges are minimal and often fall within the free tier limits Google provides each month. Cloud CDN billing adds egress charges for data delivered from edge cache locations to end users, but these rates are generally lower than direct Cloud Storage egress rates and the performance benefits justify the cost for high-traffic sites. Load balancer costs include a fixed hourly charge for each forwarding rule plus charges based on the volume of data processed. To minimize costs, use appropriate cache control headers to maximize your CDN cache hit ratio and reduce origin egress, choose a Cloud Storage region close to your primary user base, and regularly review your billing reports in the Cloud Console to identify any unexpected charges before they accumulate significantly.
Secure and automate the publishing process
Securing your static website hosted on Google Cloud involves several layers of protection that go beyond simply enabling HTTPS. Google Cloud Armor is a web application firewall and DDoS protection service that integrates with your load balancer and allows you to define security policies that block malicious traffic before it reaches your origin. For a public static website, configuring Cloud Armor with basic DDoS protection and rate limiting rules provides a meaningful security layer against automated attacks and traffic floods that could otherwise drive up your costs or degrade performance for legitimate users. At the Cloud Storage level, ensure that your bucket permissions follow the principle of least privilege by granting public read access only to the specific objects that need to be publicly accessible and keeping any sensitive configuration files or non-public assets in separate private buckets. Enable audit logging for your bucket to maintain a record of all access and administrative actions, which is useful for compliance purposes and for investigating any unexpected access patterns. Regularly review your IAM permissions to ensure that only authorized team members have the ability to modify bucket contents or change configuration settings that affect your live website.
Automating your static website deployment process eliminates manual errors, speeds up your release cycle, and ensures consistent behavior every time you push an update. Google Cloud Build is a fully managed continuous integration and delivery service that can be configured to automatically build and deploy your static website to Cloud Storage whenever you push changes to a connected source code repository such as GitHub or Cloud Source Repositories. A simple Cloud Build configuration file defines the steps needed to install dependencies, build your site, sync files to your bucket, and invalidate the CDN cache in a single automated pipeline. For teams using GitHub Actions, Google provides official actions that allow you to authenticate with Google Cloud and run gsutil commands as part of your GitHub workflow. This approach is popular with developers who prefer to keep their CI/CD configuration within their source code repository rather than managing a separate Cloud Build setup. Whichever automation approach you choose, include a cache invalidation step at the end of your deployment pipeline to ensure that your CDN edge servers immediately begin serving your updated content to users around the world without any manual intervention after each release.
Build a disposable sample site with a page, a stylesheet and one image. Deploy it to a dedicated test bucket, expose it using a supported HTTPS load-balancer configuration, then confirm the response headers, cache-hit behavior and certificate validity. Change the stylesheet and test whether users see the new version according to the intended caching policy.
Use immutable file names or a carefully planned invalidation process for important updates. Restrict public access to the files explicitly intended to be public; keep administrative access and deployment credentials separate from audience permissions. The result should be a reliable publishing workflow with documented controls, not an assumption that caching removes every failure mode.