{"content_id":"nz3psdk2a0","slug":"low-involvement-web-static-generation-html-cache","locale":"en","schema_type":"TechArticle","category":"knowledge_base","category_name":"Knowledge Base","title":"Low-Involvement Sites: Static Generation and HTML Caching","summary":"Technical design for low-involvement websites requires checking both the body content in the initial HTML and the CDN's HTML cache. A TTFB of 0.8 seconds is a reference value for performance improvements, and cache coverage and updates after edits are also part of the design.","sponsorship_disclosure":null,"affiliate_disclosure":null,"commerce_disclosure":null,"author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["Including the main content in the initial HTML can reduce reliance on JavaScript execution.","Google runs JavaScript, so React use alone is not enough to conclude that search crawling will fail.","A TTFB of at most 0.8 seconds is a reference value for performance improvements, not the total page load time.","Cloudflare CDN does not cache HTML by default, so you need to check the cache rules for public pages.","HTML caching requires excluding login pages and setting a policy for refreshing the cache after content edits."],"content_markdown":"To help search engines crawl low-involvement websites, include the core content in the initial HTML. Static generation and CDN caching of HTML are useful for public content. However, achieving a TTFB of 0.8 seconds alone does not guarantee visibility in search results.\n\nThe TTFB figure is based on the web.dev document updated on November 18, 2025.\n\n## Technical conditions to check first on low-involvement websites\n\nIn this article, low-involvement websites are websites where people briefly check the information they need. Rendering and delivery speed are technical checkpoints for these sites. However, these two factors alone cannot explain all differences in search visibility.\n\nCrawling is the process by which a bot fetches a page. Indexing is the process of preparing the fetched content for search. Google explains that not every crawled page is included in the index. [Google crawl budget guide](https://developers.google.com/crawling/docs/crawl-budget)\n\n| Checkpoint | What to check | Problem to address |\n| --- | --- | --- |\n| Initial HTML | Whether the response includes the title and core content | Dependence on additional execution to read the content |\n| Rendering | Whether content appears correctly after JavaScript runs | Missing content caused by execution errors or blocking |\n| TTFB | Time until the first response arrives | Delays in connections and server responses |\n| HTML caching | Whether public documents are reused through the CDN | The cost of repeatedly requesting the origin server |\n| Indexing status | How Google has processed the URL | Confusing successful crawling with inclusion in search |\n\n## Why React pages can appear as empty HTML\n\nThe initial HTML of a React page depends on how it is implemented. Generating the content in the browser is called CSR. With this approach, the first response may contain only executable code, without the content.\n\nGoogle uses Chromium to run JavaScript. Pages may wait for rendering after they are crawled. Blocked pages or files may be excluded from rendering. Not all bots run JavaScript, either. [Google JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)\n\nSo do not judge crawling status solely by whether the page looks correct on screen. First, check whether the initial response contains the content. You can check Google's rendered output using URL Inspection in Search Console.\n\n## Comparing static generation and server rendering\n\nYou can choose how to generate HTML based on how the public content is updated. Static generation creates HTML before a request. Server rendering creates HTML on the server when a request arrives. These approaches can also be used with React. [web.dev guide to rendering approaches](https://web.dev/articles/rendering-on-the-web)\n\n| Approach | When HTML is generated | When to consider it | Operational checks |\n| --- | --- | --- | --- |\n| Client-side rendering CSR | When JavaScript runs in the browser | Screens with frequent user interaction | Execution and requests needed before the content appears |\n| Static generation SSG | At build time or when content is created | Public documents that show the same content to visitors | Regeneration and deployment after edits |\n| Server rendering SSR | When a page request is processed | Screens that assemble up-to-date content for each request | Time spent retrieving data and generating HTML |\n| Prerendering | When the app runs before deployment to produce HTML | Providing the initial content of an existing app in advance | JavaScript needed for subsequent functionality |\n\nStatic generation and CDNs serve different roles. Static generation is a choice about when HTML is created. A CDN is a system for delivering and reusing content. Server-generated HTML can also be cached on a CDN if it meets the conditions.\n\n## What does a TTFB of 0.8 seconds mean?\n\nTTFB is the time from the start of navigation to the first byte of the response. web.dev suggests **at most 0.8 seconds** as a rough target for most sites. This differs from the time it takes to display the entire page. TTFB itself is not a Core Web Vitals metric. [web.dev explanation of TTFB](https://web.dev/articles/ttfb)\n\nTTFB includes delays beyond internal server processing. A DNS lookup finds the connection address for a domain. Establishing TCP and TLS connections can also take time. Redirects to another address also have an effect.\n\n- Time spent on DNS lookups and connection setup\n- Time for requests and responses to travel across the network\n- Time for the origin server to retrieve data and generate HTML\n- Time spent on redirects before the first response\n\nA server's location in Seoul alone does not mean its TTFB is more than 0.8 seconds. Results vary depending on the connection location and whether connections are reused. Google's crawlers primarily use US IP addresses. However, they may also connect from IP addresses in other countries. [Technical characteristics of Google crawlers](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en)\n\nPersistent response delays affect Google's crawl capacity. Server errors also cause crawl volume to decrease. However, there is no rule that crawling stops if TTFB exceeds 0.8 seconds once. Page quality and update frequency also affect crawl demand. [Google crawl budget guide](https://developers.google.com/crawling/docs/crawl-budget)\n\n## Why you need to check HTML caching on a CDN\n\nThe Cloudflare CDN does not cache HTML by default. Even if images or CSS are cached, you need to check the content document separately. For the default behavior of other CDNs, check the service's documentation.\n\n\u003e The Cloudflare CDN does not cache HTML or JSON by default.\n\u003e\n\u003e Cloudflare, Default cache behavior\n\nThis means that HTML and JSON are not cached by default. You can use Cache Rules to make public HTML eligible for caching. Conditions such as response headers and cookies also affect whether it is actually stored. [Cloudflare default cache behavior](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)\n\nCaching reuses stored responses. Connecting to a CDN does not instantly replicate every document worldwide. Cloudflare caches content at the data center that handles the request. Requests for content not in the cache may need to reach the origin server. [Cloudflare cache getting started guide](https://developers.cloudflare.com/cache/get-started/)\n\nExclude personalized pages when applying cache rules to public HTML. Cloudflare warns that caching dynamic HTML can expose one person's information to another. Do not cache login or account pages. [Cloudflare Cache Everything precautions](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/)\n\n## Caching criteria by page conditions\n\nWhether visitors see the same content is the starting point for deciding what to cache. Public explanatory content is well suited to shared reuse. Responses that vary depending on login status need separate handling.\n\n| Page condition | Configuration to consider | What else to check |\n| --- | --- | --- |\n| The same explanatory content is shown to visitors | Static generation and public HTML caching | Regeneration and cache refresh after edits |\n| Public content includes frequently changing figures | Separate update methods for the content and changing data | The reference time for the figures and what appears if an update fails |\n| The latest public information is needed at request time | Consider server rendering and conditional caching | Acceptable information delay |\n| Login, account, and payment screens | Exclude from shared HTML caching | Authentication cookies and user-specific responses |\n| Public documents are offered in multiple languages | Language-specific URLs and caching for each document | Links between translations and updates for each language |\n\nLoading real-time data later makes it easier to keep the main content static. However, do not defer all core content needed for search. Doing so can conflict with the purpose of providing initial HTML.\n\n## Common mistakes and verification criteria\n\nJudging results by technology names or settings screens alone makes it easy to miss errors. Check the actual HTML alongside response headers. The following are states that need to be distinguished.\n\n| Common assumption | What to verify |\n| --- | --- |\n| Search bots cannot read React sites | Initial HTML and Google's rendered output |\n| A TTFB of 0.8 seconds means the entire page is displayed | Time from the first response until the content appears |\n| HTML is cached because a CDN is connected | Cache status of HTML requests |\n| Static files always contain the latest content | The last generation time and deployed content |\n| A fast response means inclusion in search is complete | Indexing status in Search Console |\n| One cache hit is enough to judge global speed | Measurements by connection region and cache hit status |\n\nCloudflare's `CF-Cache-Status` is a header that shows cache status. `HIT` means the response was found in the cache. `MISS` means it was not in the cache at the time of the request and was fetched from the origin. `DYNAMIC` means it was not treated as eligible for caching. [Cloudflare cache response explanations](https://developers.cloudflare.com/cache/concepts/cache-responses/)\n\n## Refreshing the cache after content edits\n\nFor static files and CDN caches, you also need to design the process for applying edits. Even if you change the source, old content will still be delivered if the previous cache remains. If you publish HTML and JSON together, their content must also match.\n\nThe following is a checking sequence for maintaining documents and data files together.\n\n1. Finalize the changes in the source data.\n2. Regenerate the HTML and data files from the same revised version.\n3. Deploy the new files, then refresh the cache for the changed URLs.\n4. Request each URL again to check that the edits match.\n\nCloudflare recommends purging the cache by URL. Purging removes stored responses. Regenerating static HTML is a separate task. Therefore, connect file generation and cache refresh within the same deployment process. [Cloudflare cache purge guide](https://developers.cloudflare.com/cache/how-to/purge-cache/)\n\nSet update intervals according to the information delay the content allows. Explanatory content and real-time figures do not need the same schedule. A short cache lifetime alone cannot solve every update problem.\n\n## hreflang criteria for multilingual sites\n\n`hreflang` links the language- and region-specific URLs for the same content. It does not create translations. It helps Google find the appropriate language version for visitors.\n\n| Implementation location | How it is specified | What to check when choosing |\n| --- | --- | --- |\n| HTML | Specify alternate language links in the document's `head` | Whether they can be managed in each page template |\n| HTTP headers | Specify them in the response's `Link` header | Whether the headers can be managed on the server |\n| Sitemap | Specify relationships between language-specific URLs in the sitemap | Whether the document list can be managed in bulk |\n\nGoogle treats these methods equally. Therefore, the information does not have to appear only in HTML. Each language document must identify the alternate language documents, including itself. Also check the links between corresponding pages. [Google guide to multilingual pages](https://developers.google.com/search/docs/specialty/international/localized-versions)\n\n## Steps to verify deployment results\n\nAfter deployment, verify content delivery and cache behavior separately. Record the measurement region and cache status alongside speed measurements. Checking in the following order makes it easier to identify where problems occur.\n\n1. Check the HTML document response in browser developer tools. See whether the response includes the core content.\n2. Check the rendered HTML using URL Inspection in Search Console. Separately check the actual indexing status as well.\n3. Check the cache headers in the HTML response. On Cloudflare, read `CF-Cache-Status`.\n4. Measure the same document from key visitor regions. Distinguish cache misses from cache hits.\n5. Edit the content, then verify the update results. Also check that login pages are excluded from caching.\n\nCloudflare warns that excessive caching of dynamic HTML can break login functionality. Do not cache login forms or authenticated pages. After making changes, also check that authentication cookies are retained. [Cloudflare login troubleshooting guide](https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/)\n\n## Implementation requirements to give an AI coding assistant\n\nAsk AI for verifiable results along with technology names. It is useful to specify the content of the initial HTML and what must be excluded from caching. The following is an example request for building public knowledge pages.\n\n```text\nInclude the core content of public knowledge pages in the initial HTML.\nConsider static generation first for public documents.\nExplain separately how changing data will be updated.\nCheck whether the CDN caches HTML.\nExclude login, account, and payment pages from shared caching.\nConnect static file regeneration with cache refresh when content is edited.\nSet up hreflang links if there are multilingual pages.\nProvide methods to verify the initial HTML, cache status, and whether edits have been applied.\n```","content_html":"\u003cp\u003eTo help search engines crawl low-involvement websites, include the core content in the initial HTML. Static generation and CDN caching of HTML are useful for public content. However, achieving a TTFB of 0.8 seconds alone does not guarantee visibility in search results.\u003c/p\u003e\n\u003cp\u003eThe TTFB figure is based on the web.dev document updated on November 18, 2025.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#technical-conditions-to-check-first-on-low-involvement-websites\" class=\"anchor\" id=\"technical-conditions-to-check-first-on-low-involvement-websites\"\u003e\u003c/a\u003eTechnical conditions to check first on low-involvement websites\u003c/h2\u003e\n\u003cp\u003eIn this article, low-involvement websites are websites where people briefly check the information they need. Rendering and delivery speed are technical checkpoints for these sites. However, these two factors alone cannot explain all differences in search visibility.\u003c/p\u003e\n\u003cp\u003eCrawling is the process by which a bot fetches a page. Indexing is the process of preparing the fetched content for search. Google explains that not every crawled page is included in the index. \u003ca href=\"https://developers.google.com/crawling/docs/crawl-budget\"\u003eGoogle crawl budget guide\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCheckpoint\u003c/th\u003e\n\u003cth\u003eWhat to check\u003c/th\u003e\n\u003cth\u003eProblem to address\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Checkpoint\"\u003eInitial HTML\u003c/td\u003e\n\u003ctd data-label=\"What to check\"\u003eWhether the response includes the title and core content\u003c/td\u003e\n\u003ctd data-label=\"Problem to address\"\u003eDependence on additional execution to read the content\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Checkpoint\"\u003eRendering\u003c/td\u003e\n\u003ctd data-label=\"What to check\"\u003eWhether content appears correctly after JavaScript runs\u003c/td\u003e\n\u003ctd data-label=\"Problem to address\"\u003eMissing content caused by execution errors or blocking\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Checkpoint\"\u003eTTFB\u003c/td\u003e\n\u003ctd data-label=\"What to check\"\u003eTime until the first response arrives\u003c/td\u003e\n\u003ctd data-label=\"Problem to address\"\u003eDelays in connections and server responses\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Checkpoint\"\u003eHTML caching\u003c/td\u003e\n\u003ctd data-label=\"What to check\"\u003eWhether public documents are reused through the CDN\u003c/td\u003e\n\u003ctd data-label=\"Problem to address\"\u003eThe cost of repeatedly requesting the origin server\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Checkpoint\"\u003eIndexing status\u003c/td\u003e\n\u003ctd data-label=\"What to check\"\u003eHow Google has processed the URL\u003c/td\u003e\n\u003ctd data-label=\"Problem to address\"\u003eConfusing successful crawling with inclusion in search\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#why-react-pages-can-appear-as-empty-html\" class=\"anchor\" id=\"why-react-pages-can-appear-as-empty-html\"\u003e\u003c/a\u003eWhy React pages can appear as empty HTML\u003c/h2\u003e\n\u003cp\u003eThe initial HTML of a React page depends on how it is implemented. Generating the content in the browser is called CSR. With this approach, the first response may contain only executable code, without the content.\u003c/p\u003e\n\u003cp\u003eGoogle uses Chromium to run JavaScript. Pages may wait for rendering after they are crawled. Blocked pages or files may be excluded from rendering. Not all bots run JavaScript, either. \u003ca href=\"https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics\"\u003eGoogle JavaScript SEO basics\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eSo do not judge crawling status solely by whether the page looks correct on screen. First, check whether the initial response contains the content. You can check Google's rendered output using URL Inspection in Search Console.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#comparing-static-generation-and-server-rendering\" class=\"anchor\" id=\"comparing-static-generation-and-server-rendering\"\u003e\u003c/a\u003eComparing static generation and server rendering\u003c/h2\u003e\n\u003cp\u003eYou can choose how to generate HTML based on how the public content is updated. Static generation creates HTML before a request. Server rendering creates HTML on the server when a request arrives. These approaches can also be used with React. \u003ca href=\"https://web.dev/articles/rendering-on-the-web\"\u003eweb.dev guide to rendering approaches\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eApproach\u003c/th\u003e\n\u003cth\u003eWhen HTML is generated\u003c/th\u003e\n\u003cth\u003eWhen to consider it\u003c/th\u003e\n\u003cth\u003eOperational checks\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Approach\"\u003eClient-side rendering CSR\u003c/td\u003e\n\u003ctd data-label=\"When HTML is generated\"\u003eWhen JavaScript runs in the browser\u003c/td\u003e\n\u003ctd data-label=\"When to consider it\"\u003eScreens with frequent user interaction\u003c/td\u003e\n\u003ctd data-label=\"Operational checks\"\u003eExecution and requests needed before the content appears\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Approach\"\u003eStatic generation SSG\u003c/td\u003e\n\u003ctd data-label=\"When HTML is generated\"\u003eAt build time or when content is created\u003c/td\u003e\n\u003ctd data-label=\"When to consider it\"\u003ePublic documents that show the same content to visitors\u003c/td\u003e\n\u003ctd data-label=\"Operational checks\"\u003eRegeneration and deployment after edits\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Approach\"\u003eServer rendering SSR\u003c/td\u003e\n\u003ctd data-label=\"When HTML is generated\"\u003eWhen a page request is processed\u003c/td\u003e\n\u003ctd data-label=\"When to consider it\"\u003eScreens that assemble up-to-date content for each request\u003c/td\u003e\n\u003ctd data-label=\"Operational checks\"\u003eTime spent retrieving data and generating HTML\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Approach\"\u003ePrerendering\u003c/td\u003e\n\u003ctd data-label=\"When HTML is generated\"\u003eWhen the app runs before deployment to produce HTML\u003c/td\u003e\n\u003ctd data-label=\"When to consider it\"\u003eProviding the initial content of an existing app in advance\u003c/td\u003e\n\u003ctd data-label=\"Operational checks\"\u003eJavaScript needed for subsequent functionality\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eStatic generation and CDNs serve different roles. Static generation is a choice about when HTML is created. A CDN is a system for delivering and reusing content. Server-generated HTML can also be cached on a CDN if it meets the conditions.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#what-does-a-ttfb-of-08-seconds-mean\" class=\"anchor\" id=\"what-does-a-ttfb-of-08-seconds-mean\"\u003e\u003c/a\u003eWhat does a TTFB of 0.8 seconds mean?\u003c/h2\u003e\n\u003cp\u003eTTFB is the time from the start of navigation to the first byte of the response. web.dev suggests \u003cstrong\u003eat most 0.8 seconds\u003c/strong\u003e as a rough target for most sites. This differs from the time it takes to display the entire page. TTFB itself is not a Core Web Vitals metric. \u003ca href=\"https://web.dev/articles/ttfb\"\u003eweb.dev explanation of TTFB\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eTTFB includes delays beyond internal server processing. A DNS lookup finds the connection address for a domain. Establishing TCP and TLS connections can also take time. Redirects to another address also have an effect.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTime spent on DNS lookups and connection setup\u003c/li\u003e\n\u003cli\u003eTime for requests and responses to travel across the network\u003c/li\u003e\n\u003cli\u003eTime for the origin server to retrieve data and generate HTML\u003c/li\u003e\n\u003cli\u003eTime spent on redirects before the first response\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eA server's location in Seoul alone does not mean its TTFB is more than 0.8 seconds. Results vary depending on the connection location and whether connections are reused. Google's crawlers primarily use US IP addresses. However, they may also connect from IP addresses in other countries. \u003ca href=\"https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en\"\u003eTechnical characteristics of Google crawlers\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003ePersistent response delays affect Google's crawl capacity. Server errors also cause crawl volume to decrease. However, there is no rule that crawling stops if TTFB exceeds 0.8 seconds once. Page quality and update frequency also affect crawl demand. \u003ca href=\"https://developers.google.com/crawling/docs/crawl-budget\"\u003eGoogle crawl budget guide\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#why-you-need-to-check-html-caching-on-a-cdn\" class=\"anchor\" id=\"why-you-need-to-check-html-caching-on-a-cdn\"\u003e\u003c/a\u003eWhy you need to check HTML caching on a CDN\u003c/h2\u003e\n\u003cp\u003eThe Cloudflare CDN does not cache HTML by default. Even if images or CSS are cached, you need to check the content document separately. For the default behavior of other CDNs, check the service's documentation.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe Cloudflare CDN does not cache HTML or JSON by default.\u003c/p\u003e\n\u003cp\u003eCloudflare, Default cache behavior\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThis means that HTML and JSON are not cached by default. You can use Cache Rules to make public HTML eligible for caching. Conditions such as response headers and cookies also affect whether it is actually stored. \u003ca href=\"https://developers.cloudflare.com/cache/concepts/default-cache-behavior/\"\u003eCloudflare default cache behavior\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eCaching reuses stored responses. Connecting to a CDN does not instantly replicate every document worldwide. Cloudflare caches content at the data center that handles the request. Requests for content not in the cache may need to reach the origin server. \u003ca href=\"https://developers.cloudflare.com/cache/get-started/\"\u003eCloudflare cache getting started guide\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eExclude personalized pages when applying cache rules to public HTML. Cloudflare warns that caching dynamic HTML can expose one person's information to another. Do not cache login or account pages. \u003ca href=\"https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/\"\u003eCloudflare Cache Everything precautions\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#caching-criteria-by-page-conditions\" class=\"anchor\" id=\"caching-criteria-by-page-conditions\"\u003e\u003c/a\u003eCaching criteria by page conditions\u003c/h2\u003e\n\u003cp\u003eWhether visitors see the same content is the starting point for deciding what to cache. Public explanatory content is well suited to shared reuse. Responses that vary depending on login status need separate handling.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePage condition\u003c/th\u003e\n\u003cth\u003eConfiguration to consider\u003c/th\u003e\n\u003cth\u003eWhat else to check\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Page condition\"\u003eThe same explanatory content is shown to visitors\u003c/td\u003e\n\u003ctd data-label=\"Configuration to consider\"\u003eStatic generation and public HTML caching\u003c/td\u003e\n\u003ctd data-label=\"What else to check\"\u003eRegeneration and cache refresh after edits\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Page condition\"\u003ePublic content includes frequently changing figures\u003c/td\u003e\n\u003ctd data-label=\"Configuration to consider\"\u003eSeparate update methods for the content and changing data\u003c/td\u003e\n\u003ctd data-label=\"What else to check\"\u003eThe reference time for the figures and what appears if an update fails\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Page condition\"\u003eThe latest public information is needed at request time\u003c/td\u003e\n\u003ctd data-label=\"Configuration to consider\"\u003eConsider server rendering and conditional caching\u003c/td\u003e\n\u003ctd data-label=\"What else to check\"\u003eAcceptable information delay\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Page condition\"\u003eLogin, account, and payment screens\u003c/td\u003e\n\u003ctd data-label=\"Configuration to consider\"\u003eExclude from shared HTML caching\u003c/td\u003e\n\u003ctd data-label=\"What else to check\"\u003eAuthentication cookies and user-specific responses\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Page condition\"\u003ePublic documents are offered in multiple languages\u003c/td\u003e\n\u003ctd data-label=\"Configuration to consider\"\u003eLanguage-specific URLs and caching for each document\u003c/td\u003e\n\u003ctd data-label=\"What else to check\"\u003eLinks between translations and updates for each language\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLoading real-time data later makes it easier to keep the main content static. However, do not defer all core content needed for search. Doing so can conflict with the purpose of providing initial HTML.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#common-mistakes-and-verification-criteria\" class=\"anchor\" id=\"common-mistakes-and-verification-criteria\"\u003e\u003c/a\u003eCommon mistakes and verification criteria\u003c/h2\u003e\n\u003cp\u003eJudging results by technology names or settings screens alone makes it easy to miss errors. Check the actual HTML alongside response headers. The following are states that need to be distinguished.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCommon assumption\u003c/th\u003e\n\u003cth\u003eWhat to verify\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eSearch bots cannot read React sites\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eInitial HTML and Google's rendered output\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eA TTFB of 0.8 seconds means the entire page is displayed\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eTime from the first response until the content appears\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eHTML is cached because a CDN is connected\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eCache status of HTML requests\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eStatic files always contain the latest content\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eThe last generation time and deployed content\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eA fast response means inclusion in search is complete\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eIndexing status in Search Console\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Common assumption\"\u003eOne cache hit is enough to judge global speed\u003c/td\u003e\n\u003ctd data-label=\"What to verify\"\u003eMeasurements by connection region and cache hit status\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eCloudflare's \u003ccode\u003eCF-Cache-Status\u003c/code\u003e is a header that shows cache status. \u003ccode\u003eHIT\u003c/code\u003e means the response was found in the cache. \u003ccode\u003eMISS\u003c/code\u003e means it was not in the cache at the time of the request and was fetched from the origin. \u003ccode\u003eDYNAMIC\u003c/code\u003e means it was not treated as eligible for caching. \u003ca href=\"https://developers.cloudflare.com/cache/concepts/cache-responses/\"\u003eCloudflare cache response explanations\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#refreshing-the-cache-after-content-edits\" class=\"anchor\" id=\"refreshing-the-cache-after-content-edits\"\u003e\u003c/a\u003eRefreshing the cache after content edits\u003c/h2\u003e\n\u003cp\u003eFor static files and CDN caches, you also need to design the process for applying edits. Even if you change the source, old content will still be delivered if the previous cache remains. If you publish HTML and JSON together, their content must also match.\u003c/p\u003e\n\u003cp\u003eThe following is a checking sequence for maintaining documents and data files together.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eFinalize the changes in the source data.\u003c/li\u003e\n\u003cli\u003eRegenerate the HTML and data files from the same revised version.\u003c/li\u003e\n\u003cli\u003eDeploy the new files, then refresh the cache for the changed URLs.\u003c/li\u003e\n\u003cli\u003eRequest each URL again to check that the edits match.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eCloudflare recommends purging the cache by URL. Purging removes stored responses. Regenerating static HTML is a separate task. Therefore, connect file generation and cache refresh within the same deployment process. \u003ca href=\"https://developers.cloudflare.com/cache/how-to/purge-cache/\"\u003eCloudflare cache purge guide\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eSet update intervals according to the information delay the content allows. Explanatory content and real-time figures do not need the same schedule. A short cache lifetime alone cannot solve every update problem.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#hreflang-criteria-for-multilingual-sites\" class=\"anchor\" id=\"hreflang-criteria-for-multilingual-sites\"\u003e\u003c/a\u003ehreflang criteria for multilingual sites\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003ehreflang\u003c/code\u003e links the language- and region-specific URLs for the same content. It does not create translations. It helps Google find the appropriate language version for visitors.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eImplementation location\u003c/th\u003e\n\u003cth\u003eHow it is specified\u003c/th\u003e\n\u003cth\u003eWhat to check when choosing\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Implementation location\"\u003eHTML\u003c/td\u003e\n\u003ctd data-label=\"How it is specified\"\u003eSpecify alternate language links in the document's \u003ccode\u003ehead\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"What to check when choosing\"\u003eWhether they can be managed in each page template\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Implementation location\"\u003eHTTP headers\u003c/td\u003e\n\u003ctd data-label=\"How it is specified\"\u003eSpecify them in the response's \u003ccode\u003eLink\u003c/code\u003e header\u003c/td\u003e\n\u003ctd data-label=\"What to check when choosing\"\u003eWhether the headers can be managed on the server\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Implementation location\"\u003eSitemap\u003c/td\u003e\n\u003ctd data-label=\"How it is specified\"\u003eSpecify relationships between language-specific URLs in the sitemap\u003c/td\u003e\n\u003ctd data-label=\"What to check when choosing\"\u003eWhether the document list can be managed in bulk\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eGoogle treats these methods equally. Therefore, the information does not have to appear only in HTML. Each language document must identify the alternate language documents, including itself. Also check the links between corresponding pages. \u003ca href=\"https://developers.google.com/search/docs/specialty/international/localized-versions\"\u003eGoogle guide to multilingual pages\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#steps-to-verify-deployment-results\" class=\"anchor\" id=\"steps-to-verify-deployment-results\"\u003e\u003c/a\u003eSteps to verify deployment results\u003c/h2\u003e\n\u003cp\u003eAfter deployment, verify content delivery and cache behavior separately. Record the measurement region and cache status alongside speed measurements. Checking in the following order makes it easier to identify where problems occur.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eCheck the HTML document response in browser developer tools. See whether the response includes the core content.\u003c/li\u003e\n\u003cli\u003eCheck the rendered HTML using URL Inspection in Search Console. Separately check the actual indexing status as well.\u003c/li\u003e\n\u003cli\u003eCheck the cache headers in the HTML response. On Cloudflare, read \u003ccode\u003eCF-Cache-Status\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMeasure the same document from key visitor regions. Distinguish cache misses from cache hits.\u003c/li\u003e\n\u003cli\u003eEdit the content, then verify the update results. Also check that login pages are excluded from caching.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eCloudflare warns that excessive caching of dynamic HTML can break login functionality. Do not cache login forms or authenticated pages. After making changes, also check that authentication cookies are retained. \u003ca href=\"https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/\"\u003eCloudflare login troubleshooting guide\u003c/a\u003e\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#implementation-requirements-to-give-an-ai-coding-assistant\" class=\"anchor\" id=\"implementation-requirements-to-give-an-ai-coding-assistant\"\u003e\u003c/a\u003eImplementation requirements to give an AI coding assistant\u003c/h2\u003e\n\u003cp\u003eAsk AI for verifiable results along with technology names. It is useful to specify the content of the initial HTML and what must be excluded from caching. The following is an example request for building public knowledge pages.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eInclude the core content of public knowledge pages in the initial HTML.\n\u003c/span\u003e\u003cspan\u003eConsider static generation first for public documents.\n\u003c/span\u003e\u003cspan\u003eExplain separately how changing data will be updated.\n\u003c/span\u003e\u003cspan\u003eCheck whether the CDN caches HTML.\n\u003c/span\u003e\u003cspan\u003eExclude login, account, and payment pages from shared caching.\n\u003c/span\u003e\u003cspan\u003eConnect static file regeneration with cache refresh when content is edited.\n\u003c/span\u003e\u003cspan\u003eSet up hreflang links if there are multilingual pages.\n\u003c/span\u003e\u003cspan\u003eProvide methods to verify the initial HTML, cache status, and whether edits have been applied.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n","tags":["AI Development","Content monetization","Technology strategy","Development Tools"],"faqs":[{"question":"Do low-involvement websites need to be built with a specific framework?","answer":"No specific framework is required. Check whether the main content is included in the initial HTML. You should also review how public content is cached and updated."},{"question":"Doesn't Google execute JavaScript?","answer":"Google executes JavaScript using Chromium. However, rendering delays and blocked resources can affect processing. Including the main content in the initial HTML can reduce reliance on additional execution."},{"question":"Can sites built with React also use static generation?","answer":"React can also generate static HTML. It also supports generating HTML on the server. Whether a site uses React alone does not tell you what its initial HTML contains."},{"question":"If TTFB is at most 0.8 seconds, has the page fully loaded?","answer":"TTFB is the time it takes for the first response byte to arrive. Image downloads and page rendering may continue afterward. It should be distinguished from the total page load time."},{"question":"Will a page be excluded from Google search if its TTFB is more than 0.8 seconds?","answer":"0.8 seconds is a rough performance target suggested by web.dev. It is not a rule that exceeding it leads to exclusion from search. Persistent response delays and server errors can affect crawl capacity."},{"question":"Does using a server in Korea put a global site at a disadvantage?","answer":"Visitors who are far away may experience network latency. However, location alone does not determine a specific response time. Base your judgment on actual measurements from the main regions your visitors access the site from."},{"question":"Does connecting Cloudflare automatically cache HTML too?","answer":"Cloudflare CDN does not cache HTML or JSON by default. Check the Cache Rules to apply to public HTML. After applying the rules, check the response headers to verify the actual cache status."},{"question":"Is the first request always fast even when it is not in the CDN cache?","answer":"A request that is not in the cache may need to fetch a response from the origin server. Its latency may therefore differ from that of a cache hit. Measure the two cases separately."},{"question":"Is it okay to cache HTML on login pages too?","answer":"Do not cache login pages or authenticated HTML. Cloudflare warns that excessive caching can break login behavior. There is also a risk of user-specific information being delivered to other visitors."},{"question":"What should I do if I edit a post on a static site but still see the old content?","answer":"First, check whether the new HTML has been generated and deployed. Then refresh the CDN cache for the changed URL. Clearing the cache alone does not regenerate static files."},{"question":"Does hreflang have to be included only in HTML?","answer":"Google supports HTML, HTTP headers, and sitemaps. All three methods are equivalent from Google's perspective. Choose the method that is easiest to manage and keep the links between language versions consistent."},{"question":"Do I need to focus on managing crawl budget even for a small site?","answer":"Google's crawl budget guidance is mainly aimed at large sites that are updated frequently. If your site does not have many pages, start by updating the sitemap and checking indexing reports. If there are server errors or missing main content, resolve those issues first."}],"sources":[{"url":"https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics","title":"Google Search Central: Understand the JavaScript SEO basics","type":"source"},{"url":"https://web.dev/articles/rendering-on-the-web","title":"web.dev: Rendering on the web","type":"source"},{"url":"https://web.dev/articles/ttfb","title":"web.dev: Time to First Byte (TTFB), updated November 18, 2025","type":"data_point"},{"url":"https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en","title":"Google: Overview of Google crawlers and fetchers","type":"source"},{"url":"https://developers.google.com/crawling/docs/crawl-budget","title":"Google: Optimize your crawl budget","type":"source"},{"url":"https://developers.cloudflare.com/cache/concepts/default-cache-behavior/","title":"Cloudflare: Default cache behavior","type":"source"},{"url":"https://developers.cloudflare.com/cache/get-started/","title":"Cloudflare Cache: Get started","type":"source"},{"url":"https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/","title":"Cloudflare: Cache Level (Cache Everything)","type":"source"},{"url":"https://developers.cloudflare.com/cache/concepts/cache-responses/","title":"Cloudflare cache responses","type":"source"},{"url":"https://developers.cloudflare.com/cache/how-to/purge-cache/","title":"Cloudflare: Purge cache","type":"source"},{"url":"https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/","title":"Cloudflare: Dynamic content and login issues","type":"source"},{"url":"https://developers.google.com/search/docs/specialty/international/localized-versions","title":"Google Search Central: Tell Google about localized versions of your page","type":"source"}],"images":[{"id":2451,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNjYsInB1ciI6ImJsb2JfaWQifX0=--3301cc345476b9a82de57f9e5bdbad57a8717225/ai-cace8faa.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"보라색 케이블이 정돈된 서버 랙 옆에서 장비 상태를 살펴보는 남성","caption":"공개 페이지의 HTML 캐시는 적용 범위와 콘텐츠 수정 후 갱신 정책을 함께 설계해야 합니다.","description":null},"en":{"alt":"A man inspecting a server rack with neatly bundled purple cables","caption":"HTML caching for public pages requires defining both its scope and how it is refreshed after content changes.","description":null},"ja":{"alt":"紫色のケーブルが整然と束ねられたサーバーラックの横で機器を確認する男性","caption":"公開ページのHTMLキャッシュは、適用範囲とコンテンツ変更後の更新方針を併せて設計する必要があります。","description":null},"es":{"alt":"Un hombre revisa un rack de servidores con cables morados ordenados en haces","caption":"La caché HTML de las páginas públicas requiere definir su alcance y cómo se actualizará tras modificar el contenido.","description":null},"id":{"alt":"Seorang pria memeriksa rak server dengan kabel ungu yang tertata rapi","caption":"Cache HTML untuk halaman publik memerlukan penetapan cakupan dan kebijakan pembaruan setelah konten diubah.","description":null},"pt":{"alt":"Um homem inspeciona um rack de servidores com cabos roxos organizados em feixes","caption":"O cache HTML de páginas públicas exige definir seu escopo e como será atualizado após alterações no conteúdo.","description":null},"zh-hant":{"alt":"一名男子在伺服器機架旁檢查設備，機架內的紫色線纜整齊成束","caption":"公開頁面的 HTML 快取需要同時規劃適用範圍與內容修改後的更新政策。","description":null},"de":{"alt":"Ein Mann prüft ein Serverrack mit ordentlich gebündelten violetten Kabeln","caption":"Für den HTML-Cache öffentlicher Seiten müssen der Geltungsbereich und die Aktualisierung nach Inhaltsänderungen festgelegt werden.","description":null}}},{"id":2452,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNzIsInB1ciI6ImJsb2JfaWQifX0=--6d794cafac94909fa4ac95705b51dc5bde79c2df/ai-9e2e0147.webp","is_representative":false,"generation_method":"ai_semi","license":"ai_generated","mime_type":"image/webp","width":1536,"height":1024,"translations":{"ko":{"alt":"두 태블릿의 웹페이지를 비교하는 여성과 문서 갱신이 두 브라우저로 이어지는 도식","caption":"콘텐츠 수정 후에는 재생성한 HTML이 캐시에도 반영됐는지 확인해야 합니다.","description":null},"en":{"alt":"A woman compares web pages on two tablets beside a diagram linking a document refresh to two browser windows.","caption":"After content changes, verify that the cache also reflects the regenerated HTML.","description":null},"ja":{"alt":"2台のタブレットでウェブページを比較する女性と、文書の更新から2つのブラウザーへつながる図","caption":"コンテンツの修正後は、再生成したHTMLがキャッシュにも反映されているか確認する必要があります。","description":null},"es":{"alt":"Una mujer compara páginas web en dos tabletas junto a un diagrama de actualización de un documento.","caption":"Tras modificar el contenido, hay que comprobar que la caché también refleje el HTML regenerado.","description":null},"id":{"alt":"Seorang perempuan membandingkan halaman web di dua tablet di samping diagram pembaruan dokumen.","caption":"Setelah konten diubah, pastikan cache juga mencerminkan HTML yang dibuat ulang.","description":null},"pt":{"alt":"Uma mulher compara páginas web em dois tablets ao lado de um diagrama de atualização de um documento.","caption":"Após alterar o conteúdo, é preciso verificar se o cache também reflete o HTML regenerado.","description":null},"zh-hant":{"alt":"一名女性比較兩台平板上的網頁，旁邊的圖示呈現文件更新後連向兩個瀏覽器視窗","caption":"修改內容後，應確認快取也已反映重新產生的 HTML。","description":null},"de":{"alt":"Eine Frau vergleicht Webseiten auf zwei Tablets neben einem Diagramm zur Dokumentaktualisierung.","caption":"Nach Inhaltsänderungen muss geprüft werden, ob auch der Cache das neu generierte HTML enthält.","description":null}}}],"published_at":"2026-11-05T07:45:55+09:00","updated_at":"2026-11-05T07:45:55+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/low-involvement-web-static-generation-html-cache"}