Skip to main content
All CollectionsSite AuditTutorials
How Patches work in Site Audit
How Patches work in Site Audit

Patches let you fix simple issues on your website with one click, right in Site Audit. This explains how they work and how to set them up.

Yuri Yeromenko avatar
Written by Yuri Yeromenko
Updated over a week ago

What are Patches?

Patches let you fix issues and make changes on your website directly from Site Audit. Think of Patches more as a quick and temporary fix. If you need to fix something critical urgently and don't have time to ask your developers, or if you want to test something with the ability to easily roll it back before making the final change on your side, you can use Patches for that.

Currently in the first release of this feature, it only allows you to patch two fields: Title and Meta description. More fields are coming soon. We have plans to allow managing redirects, canonicals, robots meta tags, as well as adding and updating internal links, and lots more.

To create a Patch, you need to open an issue related to page titles or meta descriptions, or open a filter preset related to them in Page explorer, or add these fields there manually. Patchable issues are marked with a bolt icon in the All issues report.

You will see a "Patch it" input in the report next to titles and meta descriptions for each page in the report. You can draft a new title or meta description, and when all set, publish it live on your website.

Patches statuses

Patches can be saved as drafts, published, or unpublished. You can take your time and draft a title or meta description before publishing. Drafts are saved automatically when you type. And once published, you can unpublish it at any time to undo a patch.

The current status of a patch as well as the available actions can be found in the "Patch it" input:

You can also track the full history of any patch. If you're not sure when a patch was published or who edited your draft, that's the place to look at. The "Show history" link is available in the context menu of any patch.

Patches report

Even though its convenient to patch issues right in issue reports, there's also the Patches report where you can view and manage all patches you ever created for your site. There's a link to it in the header, which also shows the number of currently published patches.

The Patches report allows you to filter patches by their status and page URL, export your patches, as well as make all the same actions with patches as in issue reports or Page explorer. This report also allows to configure the Patches deployment.

Setting up Patches deployment

There will be two deployment methods available eventually:

  • JavaScript snippet: Add a JavaScript snippet to your website pages that calls a unique JavaScript file hosted by Ahrefs. All the patches you publish will be added there and shown to users when a browser or bot executes JavaScript on the page.

  • Cloudflare workers: Provide your Cloudflare API key and we’ll create workers in your account. Cloudflare will apply your published patches on the server side before showing them to users.

The first release of this feature includes only deployment via JavaScript snippets. The Cloudflare integration will be added soon.

Patches are available for all users but in order to publish them from Site Audit, your project needs an upgrade boost that supports the Patches feature. If the project is not upgraded or you don't want to use Site Audit for actual deployment, you can draft patches, export them and hand over to your developers so they can make and deploy changes on their side.

To start configuring the deployment, click the "Set up deployment" button in the Patches report header.

Here's how the JavaScript deployment works. To enable Site Audit to make changes to your pages, you need to add a JavaScript snippet to the <head> section of every page on your site. The JavaScript snippet is generated and provided during the deployment configuration.

This snippet calls a unique JavaScript file hosted by Ahrefs. All the patches you publish will be added there and applied client-side when a browser or bot executes JavaScript on the page. Note that if a bot does not execute JavaScript on your site, it won't see the changes. But that should not be a problem since Google always renders pages they rank.

Once activated, you can deactivate JavaScript deployment at any time. If you have some patches published, you'll be warned about that and you will need to confirm that they are going to be unpublished when deactivating deployment.

Important points

Please note the following important points:

  • Visibility: This is the main goal of the Patches feature but just to state it clearly. Publishing patches will make visible changes to your site. After a patch is published, people and bots visiting your site will see the changes. So it's important to ensure the changes you publish are appropriate for your site.

  • Drafting and publishing: Any user with access to a project can draft patches. However, only users with 2FA configured in their account settings can publish patches. Make sure you’ve selected the right people to have access to projects that has Patches deployment enabled, as they’ll have the ability to publish changes on your sites. Additionally, patches can only be published in projects where site ownership has been verified.

  • Project-specific: Patches are tied to projects. If you delete a project, all patches published within it will be unpublished.

  • Project boost restrictions: Patches deployment is not available on every project. Your project needs an upgrade boost that supports the Patches feature in order to publish patches. If you downgrade to a boost that does not support it, you won’t be able to publish new patches. However previously published patches will remain active.

  • Execute JavaScript: The "Execute JavaScript" option is automatically enabled in the projects where you set up JavaScript deployment. This ensures that Site Audit bot can detect changes deployed via JavaScript next time it crawls your site. Note that crawling speed may be slower with JavaScript execution, so your crawls will take longer if you had this option turned off before.

You'll be prompted to agree with these terms before activating JavaScript deployment in Site Audit.

Did this answer your question?