Changing the visibility of your GitHub Pages site

You can manage access control for your project site by publishing the site publicly or privately.

Who can use this feature?

People with admin access to a repository can change the visibility of a GitHub Pages site.

In this article

About access control for GitHub Pages sites

With access control for GitHub Pages, you can restrict access to your project site by publishing the site privately. A privately published site can only be accessed by people with read access to the repository the site is published from. You can use privately published sites to share your internal documentation or knowledge base with members of your enterprise.

Note

To publish a GitHub Pages site privately, your organization must use GitHub Enterprise Cloud. For more information about how you can try GitHub Enterprise Cloud for free, see "Setting up a trial of GitHub Enterprise Cloud."

If your enterprise uses Enterprise Managed Users, access control is not available, and all GitHub Pages sites are only accessible to other enterprise members. For more information about Enterprise Managed Users, see "About GitHub Pages."

If your organization uses GitHub Enterprise Cloud without Enterprise Managed Users, you can choose to publish your project sites privately or publicly to anyone on the internet.

Access control is available for project sites that are published from a private or internal repository that are owned by the organization. You cannot manage access control for an organization site. For more information about the types of GitHub Pages sites, see "About GitHub Pages."

About subdomains for privately published sites

Privately published sites are available at a different subdomain than publicly published sites. This ensures that your GitHub Pages site is secure from the moment it's published:

  • We automatically secure every subdomain of *.pages.github.io with a TLS certificate, and enforce HSTS to ensure that browsers always serve the page over HTTPS.
  • We use a unique subdomain for the privately published site to ensure that other repositories in your organization cannot publish content on the same origin as the site. This protects your site from "cookie tossing". This is also why we don't host GitHub Pages sites on the github.com domain.

You can see your site's unique subdomain in the "Pages" tab of your repository settings. If you're using a static site generator configured to build the site with the repository name as a path, you may need to update the settings for the static site generator when changing the site to private. For more information, see "Managing a custom domain for your GitHub Pages site" or the documentation for your static site generator.

To use a shorter and more memorable domain for your privately published site, you can configure a custom domain. For more information, see "Configuring a custom domain for your GitHub Pages site."

Changing the visibility of your GitHub Pages site

  1. On GitHub Enterprise Cloud, navigate to your site's repository.

  2. Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

    Screenshot of a repository header showing the tabs. The "Settings" tab is highlighted by a dark orange outline.

  3. In the "Code and automation" section of the sidebar, click Pages.

  4. Under "GitHub Pages", select the GitHub Pages visibility dropdown menu, then select a visibility.

  5. To see your published site, under "GitHub Pages", click Visit site.

    Screenshot of a confirmation message for GitHub Pages listing the site's URL. To the right of a long blue URL, a button labeled "Visit site" is outlined in dark orange.

Note: It can take up to 10 minutes for changes to your site to publish after you push the changes to GitHub Enterprise Cloud. If you don't see your GitHub Pages site changes reflected in your browser after an hour, see "About Jekyll build errors for GitHub Pages sites."