I plan to keep making new projects.

As each project appears, so do the documents that need to be public.

Privacy Policy, Terms of Service, Account Deletion Instructions, Data Deletion Instructions, Accessibility Statement

A Chrome extension and a web service may also need different information.

I could build a separate policy site for every project, but I did not want to maintain the same contact and operator information in several places.

That led me to one question.

What if I managed every project's policies in one place?

Using my website as a policy hub

I had just started managing babypaunch.github.io as my blog and project website.

Adding a policy section there meant I would not need to create another site each time I made something new.

Best of all, it is free.

How good is that?!

This does not mean applying one policy to every project. The website is a shared entrance, while each project’s documents remain separate.

A small project without accounts or payments may need only a privacy policy. A project with sign-in, server storage, or subscriptions may also need terms and data deletion instructions. Each project can include only the documents that match what it actually does.

Keeping them together makes their location and revision history easier to find. It does not remove the responsibility to update a policy when a feature changes. Because several projects share the same website, I also need to keep its domain and deployment healthy.

Connecting a domain I own

The default GitHub Pages address was already enough to publish policies. But I wanted a stable address that I could repeatedly submit to places such as the Chrome Web Store and Google OAuth.

I bought babypaunch.com and connected it to GitHub Pages. Cloudflare felt inexpensive for the domain purchase. The domain can remain the same even if I change hosting later, and every project can use one official address.

Using the root domain and www address correctly with GitHub Pages required four A records and one CNAME in Cloudflare DNS.

The four A records connect babypaunch.com to the GitHub Pages servers.

The CNAME connects www.babypaunch.com to the default GitHub Pages address.

I left every record in DNS-only mode without the Cloudflare proxy.

HTTP started working first.

HTTPS needed time for DNS propagation and certificate issuance, so I had to wait before I could verify it.

Showing projects before document types

The first Policies page placed accessibility and privacy links in one list. That worked with only a few documents, but it would become unclear which policy belonged to which project as the list grew.

I reorganized the page into project cards.

The URLs now follow one rule.

/policies/project/document/
/en/policies/project/document/

When a new project appears, I can add its information and the policies it needs. Korean and English pages use the same structure.

The main advantage is that the system can grow without turning into one long mixed list. If a project needs another document, it goes under that project. Visitors can choose a project first and see only the relevant policies.

There is a tradeoff. Because every policy lives under one domain, a missed renewal or deployment problem could affect several projects at once. Central management is convenient, but it also makes maintaining this website more important. (It is free, so I plan to use it for the rest of my life.)

Whenever I make a new project, I will add the policies it needs in the same place.


August 28, 2026 update: HTTPS is now working

Even after more than 24 hours, the HTTPS certificate had not been created automatically.

The DNS records already matched GitHub Pages’ recommended values.

The actual problem was a failed certificate issuance job left in GitHub Pages.

I removed the custom domain from the GitHub Pages settings, waited briefly, and added babypaunch.com again to restart certificate issuance from the beginning. After confirming that the new certificate covered both babypaunch.com and www.babypaunch.com, I enabled HTTPS enforcement.

HTTP now redirects to HTTPS automatically, and both the root domain and the www address use an encrypted connection. I also learned that when waiting does not solve the problem, checking the GitHub Pages certificate state should come before repeatedly changing DNS records.

#AI프롬프트제공

Give the following prompt to an AI to audit the URL structure, policy documents, and HTTPS connection of a policy hub shared by several projects.

Do not enter passwords, API keys, tokens, DNS account information, or personal information in the prompt.

You are a web operator auditing a shared policy hub and custom domain used by several web services.

Inspect the site information I provide and its public pages, then check the following items.

- DNS connections for the canonical domain and any additional hostnames in use
- A permanent redirect from HTTP to HTTPS
- A valid HTTPS certificate covering every public hostname
- The hosting service's custom-domain and HTTPS-enforcement status
- A consistent policy URL structure that distinguishes services and document types
- Matching policy lists and working document links in every supported language
- Missing privacy policies or other documents required for each service type and target region
- The effective date, modification date, and change history of each policy
- Long titles, addresses, and links staying inside the mobile viewport

Classify every item as `OK`, `Needs improvement`, or `Cannot verify`.

For each problem, provide the cause, the DNS, hosting, or site setting or file to change, the smallest correction, and a public-site verification method.

Do not claim legal compliance, and separate items that require professional review based on jurisdiction and service characteristics.

Complete only the fields needed for your environment, and leave unknown fields blank.

Site URL: [policy hub URL]
Site management method: [for example, a CMS, a framework, or hand-written HTML]
Available materials: [for example, a repository URL, an admin screen, or hosting settings]
DNS provider: [DNS service]
Services to register: [service names and required policies]
Supported languages: [languages to support]
Target regions: [countries or regions where the policies apply]

In one line: Instead of waiting for my projects to pile up, I made my GitHub Pages site the shared policy hub for all of them.