pages

Today you will begin to see a new workflow running called pages build and deployment in your public GitHub Pages repositories. This workflow is automatically triggered when you push to the branch configured for GitHub Pages in your repository. As the name suggests, it builds and deploys your pages site. The initial benefit of this change is enabling you to see your build logs and any errors that may occur which has been a long standing issue for Pages users. However, in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.

You may notice this workflow uses some new actions actions/pages-deploy, and actions/jekyll-build-pages. For now these actions are designed to be used in the generated workflow, however, starting early next year we will introduce some additional changes that will enable you to take advantage of them.

Learn more about GitHub Pages

Users and organizations can now verify GitHub Pages domains to protect against takeover attacks.

Learn more about verifying your custom domain for GitHub Pages

For questions, visit the GitHub Pages community

All GitHub Pages sites served from the github.io domain will now have a Permissions-Policy: interest-cohort=() header set.

Pages sites using a custom domain will not be impacted.

Learn more about GitHub Pages

For questions, visit the GitHub Pages community

When configuring a custom domain for your GitHub Pages site, we will now automatically request a certificate for both the Apex and www subdomain of that custom domain if DNS is configured appropriately. As part of this, we've also moved the GitHub Pages settings to their own dedicated tab and refreshed the setup flow to help you get everything set up with ease.

If you don't want to use both domains with GitHub Pages, we'll continue requesting a certificate for only the specific domain you configure. Custom domains that use a subdomain other than www are not affected by this change.

Learn more about custom domains in GitHub Pages.

Beginning April 15, 2021, we will stop redirecting GitHub Pages sites from *.github.com to the *.github.io domain.

Today, we serve all GitHub Pages sites from the *.github.io domain, but before 2013 we used the *.github.com domain. On April 5, 2013, we deprecated the *.github.com domain for the Pages sites and started redirecting all traffic to the new location. After April 15, 2021, we will stop doing this redirection. We are taking this action to further protect github.com overall.

How does this affect me?

If you’ve configured a custom domain for your Pages site or you directly access your site on *.github.io, you will not be affected by this change. If, however, your site still receives traffic through a redirect from *.github.com, after April 15, 2021 that URL will stop working.

To ensure all affected customers are aware of this change, during two scheduled brownouts, we will temporarily suspend redirection of Pages sites from *.github.com. The brownouts are scheduled for the following dates and times:

• April 1st, 2021 5:00pm UTC – 8:00pm UTC

• April 8th, 2021 5:00pm UTC – 8:00pm UTC

What actions should I take?

We strongly recommend that you remove any external references to *.github.com to avoid any traffic loss to your Pages sites. Additionally, we recommend that you should review your site's dependencies to check for resources that may have been hosted on Pages sites that expected a *.github.com URL. In most cases, simply updating those dependencies to use *.github.io will ensure they continue to work after April 15th.

Please contact support if you experience any issues due to these changes.

GitHub Pages now gives you the option to limit access, making the site visible only to users with access to the repository that published the Page. With access control, you can use GitHub Pages to publish and share internal documentation and knowledge across your enterprise.

As part of this release, we are introducing the following capabilities:

• Repo admins can select whether GitHub Pages sites are publicly visible or limited to users who have access to the repository.
• Both private and internal repositories support private visibility. With an internal repository, everyone in your enterprise will be able to view the Page with the same credentials they use to login to github.com
• Org admins can configure the visibility options that members will be able to select for their Page. For example, you can enforce that your members can only publish content privately.

This feature is generally available today on GitHub Enterprise Cloud. To enable access control on Pages, navigate to your repository settings, and click the dropdown menu to toggle between public and private visibility for your site.

For questions, visit the GitHub pages community

Organization owners can now disable publication of GitHub Pages sites from repositories in the organization. Disabling GitHub Pages for the organization will prevent members from creating new Pages sites but will not unpublish existing sites.

You can learn more about this new setting in our documentation.

Repositories that use GitHub Pages can now build and deploy from any branch. Publishing to the special gh-pages branch will still work the same as it always has, but you can now choose a different branch in your repository as the publishing source. This functionality also removes the hardcoded dependency on user and organization pages having a master branch.

Repositories that use GitHub Pages can now build and deploy from any branch. Publishing to the special gh-pages branch will still work the same as it always has, but you can now choose a different branch in your repository as the publishing source. This functionality also removes the hardcoded dependency on user and organization pages having a master branch.