Skip to content

Clarify CNAME record value for private Pages sites in the subdomain section - #45865

Open
7kaji wants to merge 1 commit into
github:mainfrom
7kaji:private-pages-cname-subdomain-section
Open

Clarify CNAME record value for private Pages sites in the subdomain section#45865
7kaji wants to merge 1 commit into
github:mainfrom
7kaji:private-pages-cname-subdomain-section

Conversation

@7kaji

@7kaji 7kaji commented Sep 13, 2026

Copy link
Copy Markdown

Why:

Closes:

There is no existing issue for this. It is a one-paragraph follow-up to a change the maintainers made themselves, so I opened a pull request directly. Happy to file an issue first if you would prefer that.

The "Configuring an apex domain and the www subdomain variant" section says that the CNAME record values are the same for publicly and privately published sites. That sentence was added in commit c76a1f56. The "Configuring a subdomain" section has no equivalent statement, even though that is where Changing the visibility of your GitHub Pages site sends the reader right after showing them the site's unique *.pages.github.io subdomain.

What's being changed (if available, include any code snippets, screenshots, or gifs):

This adds one paragraph to "Configuring a subdomain", directly after the CNAME step. The first and third sentences reuse the wording of the apex and www section. The second sentence is new: it names the mistake the reader is most likely to make, because the unique subdomain is the only Pages URL shown in the repository settings for a privately published site.

Written as a paragraph rather than an alert: the section already has three alerts, the next line is a warning, and the change linked above used a paragraph too.

The link uses /enterprise-cloud@latest/ because the target article is GitHub Enterprise Cloud only, while this one is versioned for both Free, Pro & Team and Enterprise Cloud.

SME review requested for the second sentence. It follows from the existing instruction that "The CNAME record should always point to <user>.github.io or <organization>.github.io", and cname_to_github_user_domain? in github/pages-health-check does not match *.pages.github.io, but I have not found it stated by GitHub directly.

Check off the following:

  • A subject matter expert (SME) has reviewed the technical accuracy of the content in this PR. In most cases, the author can be the SME. Open source contributions may require an SME review from GitHub staff.
  • The changes in this PR meet the docs fundamentals that are required for all content.
  • All CI checks are passing and the changes look good in the review environment.

@github-actions github-actions Bot added the triage Do not begin working on this issue until triaged by the team label Sep 13, 2026
@github-actions

Copy link
Copy Markdown
Contributor

How to review these changes 👓

Thank you for your contribution. To review these changes, choose one of the following options:

A Hubber will need to deploy your changes internally to review.

Table of review links

Note: Please update the URL for your staging server or codespace.

The table shows the files in the content directory that were changed in this pull request. This helps you review your changes on a staging server. Changes to the data directory are not included in this table.

Source Review Production What Changed
pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site.md fpt
ghec
fpt
ghec

Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server

🤖 This comment is automatically generated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

triage Do not begin working on this issue until triaged by the team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants