Google Ads API to Sunset Shared Ads in October

What Is Changing?

Google is discontinuing the Ad Sharing feature in the Google Ads API. This change will affect how ads are created and managed, so it is important to understand what is changing and prepare your systems accordingly.

Key dates:

• From October 15, 2025: The creation of new shared ads will be blocked.
• In the first quarter of 2026: Existing shared ads will stop serving in their current form and will be automatically converted.

Below, we explain what Ad Sharing is, why Google is removing it, and what you need to do to prepare.

What Is Ad Sharing?

Simply put, Ad Sharing allows you to create one ad and use it across multiple ad groups.

Instead of creating identical ads separately for each ad group, you could create a single ad and then associate it with every relevant group. This helped reduce duplication and save time.

Why Is Google Ads API Removing Ad Sharing?

This change is directly connected to Google’s broader transition toward asset-based advertising. The future of Google Ads is built around formats such as Responsive Search Ads (RSAs) and Performance Max campaigns.

In these formats, an ad is assembled dynamically from multiple assets, including headlines, descriptions, and images. As a result, the concept of a static ad shared across multiple ad groups has become outdated and less compatible with Google’s current advertising architecture.

How to Prepare

There is still time to prepare, but it is advisable to begin the process now to avoid disruptions to your advertising operations.

Step 1: Audit Your Application

The first step is to determine whether your application or codebase currently uses the Ad Sharing model.

Review your code, particularly the logic that interacts with AdGroupAdService. Look for any instances where your system creates a new AdGroupAd by using the resource name of an existing ad that is already associated with another ad group.

The existing logic that will soon be deprecated may conceptually look like this:

• Create an advertising unit, AdGroupAd, containing an Ad.
• Create an AdGroup.
• Create another AdGroupAd by reusing the existing Ad from the first step and associating it with the AdGroup created in the second step. This is the functionality being discontinued.

In simple terms, developers should ensure that their code does not take one existing ad and attach it to multiple ad groups. Any logic that does this must be updated.

Step 2: Update Your Ad Creation Logic

You must refactor your code so that it creates a new and unique ad for every ad group.

Instead of sharing a single ad across multiple groups, your new workflow should create a separate ad for each target ad group. You will no longer be able to create a standalone ad and then reuse it in different groups. Instead, the ad parameters must be defined as part of the ad group ad creation process.

The new compliant workflow should look like this:

• For AdGroup 1: Create an AdGroupAd containing an ad created specifically for AdGroup 1.
• For AdGroup 2: Create another AdGroupAd containing a separate ad created specifically for AdGroup 2.

Even when the ad copy is identical, the ads must be created as separate advertising objects within the API.

If you still have legacy shared Expanded Text Ads (ETAs), you should migrate them to the Responsive Search Ads format and associate each new version with only one ad group.

In simple terms, if you want to use the same ad in five different ad groups, you will need to create five identical but technically separate ads—one for each group.

Step 3: Consider the Impact on Reporting

When you stop sharing one ad across multiple groups and begin creating unique ads for each ad group, the change will affect your performance history and reporting.

Important: Performance statistics, including impressions, clicks, and conversions, are associated with an ad’s unique ID. Every newly created ad will begin with no performance history.

The historical data associated with your old shared ads will remain available, but it will not be transferred to the newly created ads.

Make sure your team or clients are informed about this change. Export and archive historical data before beginning the migration so that you can continue conducting long-term ad-level performance analysis.

In simple terms, imagine that one shared ad has accumulated 1,000 clicks. When you replace it with five new, identical ads for five different ad groups, each new ad will begin with zero clicks. The original 1,000-click history will remain available, but it will not be distributed among the new ads.

Migrating Existing Shared Ads

Step 1: Identify Shared Ads

First, create a complete list of all ads that are currently associated with more than one ad group.

SELECT
ad_group_ad.ad.id, — the unique ID of the ad itself
ad_group.id, — the unique ID of the ad group
ad_group_ad.status,
ad_group_ad.ad.type,
campaign.id,
campaign.name,
ad_group.name
FROM
ad_group_ad
WHERE
ad_group_ad.status IN (‘ENABLED’, ‘PAUSED’)
ORDER BY
ad_group_ad.ad.id, ad_group.id

If the results contain an ad_group_ad.ad.id associated with more than one ad_group.id, it means that the same ad—identified by its unique ad_group_ad.ad.id—is linked to multiple ad groups, each with its own unique ad_group.id.

If an ad is associated with more than one distinct ad group, it is considered a shared ad.

Any ad associated with more than one distinct ad group is considered a shared ad.

Step 2: Collect the Ad Content and Associated Ad Groups

For each shared ad identified in the first step, collect the following information:

• The ad content, including its headlines and descriptions.
• A complete list of the ad groups in which the ad is currently active.

Step 3: Create a New and Unique Responsive Search Ad in Each Ad Group

For the main part of the migration, loop through each ad group identified in Step 2 and create a new ResponsiveSearchAd within that group.

Best practice: If the shared ad is an Expanded Text Ad, do not simply copy its three headlines and two descriptions. Use the existing copy as a starting point and add more assets.

The strength of Responsive Search Ads comes from providing Google with a wider selection of headlines and descriptions to test. Aim to provide five short headlines, one long headline, and five descriptions.

Below is a summary of the recommended Responsive Search Ad asset limits:

The conceptual structure of the mutation operation using AdGroupAdService is as follows:

• Loop through each ad_group.resource_name collected in Step 2.
• Inside the loop, create a new AdGroupAd object.
• Assign the current ad_group.resource_name to the ad_group field.
• Create an Ad object inside the AdGroupAd.

Populate the responsive_search_ad field with the relevant assets:

• Create a list of AdTextAsset objects for the headlines.
• Create a list of AdTextAsset objects for the descriptions.
• Set the final_urls, path1, and path2 values using the information from the old ad.
• Submit the request using MutateAdGroupAds().

This process ensures that every ad group has its own unique Responsive Search Ad that is ready to serve.

Step 4: Remove the Old Shared Ads

Once the new Responsive Search Ads have been created and have passed the editorial review process, with their status set to ENABLED, you can remove the old shared ads.

• Retrieve the resource name of the old AdGroupAd. This resource represents the association between the shared ad and the ad group.
• Use AdGroupAdService to perform a mutation.
• Create an AdGroupAdOperation object within the service request.
• Set the operation’s remove field to the resource name of the AdGroupAd you want to remove.
• Call the mutateAdGroupAds method through AdGroupAdService.

Shared Ads Deprecation Timeline

Google recommends migrating shared ads manually rather than waiting for the automatic conversion process.

Manual migration is the preferred approach because it allows you to create new ads with unique images, headlines, and descriptions tailored to the audience of each ad group. More relevant ads can produce better campaign results.

Phase 1: From October 15, 2025

• You will no longer be able to create new shared ads.
• Any attempt to associate an existing ad with a new ad group will be blocked, and the API will return an error.
• If you use automated tools or scripts to share ads across ad groups, those processes will stop working.

Phase 2: From October 15, 2025, Until Q1 2026

• Existing shared ads will continue serving as usual.
• No immediate action will be applied automatically to ads that were already shared before the deadline.
• Advertisers can use this transition period to complete the migration manually.

Phase 3: Q1 2026

• Google will automatically convert all remaining shared ads.
• For every ad that is still shared, Google will create individual copies in each ad group with which the original ad was associated.

Review the official Google Ads API documentation and monitor the Google Ads Developer Blog for additional information as the conversion date approaches.

Begin auditing your systems now and share this information with your development team to ensure a smooth transition.

Automatic Conversion Process in Q1 2026

If you do not migrate your shared ads manually, Google will automatically separate them during the first quarter of 2026.

The automatic process will work as follows:

• One ad group will retain the original ad: The original ad will remain associated with only one ad group—specifically, the ad group with the lowest ID.
• Other ad groups will receive copies: Google will create a new copy of the original ad for every other ad group in which it was previously shared.
• Automatically generated content will be recreated: Settings for features such as asset automation will be copied. However, the actual machine-generated assets, such as automatically created headlines or images, will not be transferred. Google will generate an entirely new set of automated assets for each copied ad, which may affect its initial performance.