Human beings aren’t robots. With thousands upon thousands of keywords to keep track of and an assortment of settings to apply on multiple levels of your account, there’s always a possibility that you’ve overlooked something small… or something big.

Whether it’s pushing bids too far, being overly eager in your device modifiers, or forgetting to apply location targeting, mistakes can be pretty expensive. Worldwide targeting, for one, can quickly sap your budget as you serve ads in territories of no benefit to you.

But manually checking these settings can be incredibly time-consuming. What do we say to all things tedious? The answer is always scripts.

This one will do all the legwork for you. Plug in your upper limits and tell it where you’d like it to look, and it will email you a report detailing anything in your account that isn’t right. Perhaps you’ve not applied location targeting to a certain campaign? Or you’re bidding way above what you’d like for a selection of your keywords?

It’s great to run for general upkeep, but is especially helpful after a big campaign build or when you’ve made sweeping changes in your account and need some extra peace of mind.

What does it do?

The script checks user-specified settings in your account, making sure you’ve not pushed any settings further than you would like.

It runs three separate checks:

  1. Worldwide Targeting Checker: the script will flag any campaigns that don’t have any location targeting applied.
  2. Keyword Bid Upper Limit Checker: specify a max CPC limit, and the script will report any keywords which have bids set higher than that CPC. 
  3. Bid Modifier Upper Limit Checker: this will check for any troublesome bid modifiers for location, device, and ad scheduling to ensure you are not pushing bids too high. 

These ensure that you have a quick and easy way to root out any mistakes or oversights leading to inefficiency, over-aggressive bidding, and ultimately to budget wastage.

It can perform these checks within your entire account or specific campaigns (e.g. checking Brand campaigns only). You can also include or exclude paused campaigns and keywords as required.

Once the script has run, it will email you an HTML table report, flagging anything which violates the rules you have fed it.

How to use this script

You can paste the script directly into the Google Ads interface to be run on an ad hoc basis.

In the Google Ads account where you’d like the script to run, go to Tools & Settings > Bulk Actions > Scripts. Create a new script by pressing the blue plus button.

Once you’ve given the script authorization to read your account, copy and paste all of the code below into the input box. You will then need to modify the code by adding your specific criteria.

First, ensure you have added the email you would like the report to be sent to in the EMAIL_ADDRESS variable.

If you’re worried about excessive bids, ensure you set your max CPC by modifying the BID_UPPER_LIMIT. Keywords with a higher CPC than that figure will then be listed in the report.

You can also set your bid modifier limits. If, for example, you would like to be notified of any bid modifiers over 150%, you would set it to 1.5. This should be in the range of 0.1 (-90%) to 9.0 ( 900%). These limits can be set for device, ad scheduling and location separately.

Use CAMPAIGN_NAME_DOES_NOT_CONTAIN, CAMPAIGN_NAME_CONTAIN, and IGNORE_PAUSED_CAMPAIGNS to specify which campaigns you would like to investigate. Depending on the size (and state!) of your account, you will need to be selective with the criteria you choose. If you were to request a report on all keywords with a Max CPC of more than 10p, for example, you’d probably be pulling your entire account. While the script will run in such cases, you may not be able to receive email reports for such an enormous quantity of data.

Once you have pasted the code and set your criteria, save and run the script. Note: at this point you may need to scroll to the bottom of the page and reauthorize email permissions.

And, you’re set! Your report will arrive as an HTML table via email. From there you can troubleshoot any bids, modifiers, or targeting that looks inappropriate for your account.

Opinions expressed in this article are those of the guest author and not necessarily Marketing Land. Staff authors are listed here.

About The Author

Daniel Gilbert is founder and CEO of Brainlabs,the smartest performance marketing agency on the planet. As the self-proclaimed superhero of PPC, Daniel’s mission is to change the future of advertising, while creating the best place in the world to work.


Last June I had the pleasure to present at SMX Advanced about one of my favorite topics: improving the collaboration between SEOs and developers.

While my session was about JavaScript for SEO, I took the opportunity to introduce a practice that I think can solve a painful business problem: the high cost of catching SEO issues in production when you can catch them during development using automated testing techniques.

How often do you learn about a noindex meta robots tag in the wrong pages released to production and causing massive SEO traffic drop?

Let’s learn how we can prevent this error and similar ones from happening in the first place.

Automated testing in professional development

Modern professional developers need to add new features or fix bugs at a fast pace and often rely on automated testing to keep their code quality high.

During my session, I mentioned this as a perfect place to catch some SEO errors early, before their damage is too expensive.

In this article, we are going to explore this concept in detail, review some practical examples and outline the responsibilities of the developer and the SEO.

The anatomy of the front end of a modern web application

The front-end of modern web applications is generally built in a modular way using controllers, views, and components.

Controllers route page requests to the correct view of the app and the views are what you see when the page loads.

The views are further broken down into components. For example, in a search page, the grid of search results could be powered by one component.

These components can be rendered on the server-side, on the client-side or on both sides as it is the case of hybrid rendering solutions.

SEO scope

It is important to understand these concepts because not every app controller, view or component requires SEO input or automated tests.

One way to tell is to ask if the component’s functionality should be visible or not to search engine crawlers.

For example, all components or actions behind a login form are not in the scope of SEO because search engine crawlers can’t see them.

The different types of automated tests

Automated testing is a broad topic, but when it comes to SEO concerns, there are two main types of automated tests we need to learn about: unit tests and end-to-end tests.

Developers generally write unit tests to perform individual component and method level checks. The idea is to verify each part of the application works as expected separately and in isolation.

However, while the individual parts can operate correctly, they could fail when put to work together. That is where integration tests (a.k.a. end-to-end tests) come into place. They test that the components can work together too.

We should write both types of tests to check for SEO issues during development.

Let’s review some practical examples.

Writing SEO unit tests

In preparation for my presentation, I coded an AngularJS app that monitors Google Trends topics. I focused on trying to optimize it for basic SEO best practices.

In Angular, we can use Jasmine to write unit tests. Let’s review what unit tests look like and what we can do with them.

As an example, let’s look at the Category Topics component in our app, which is responsible for listing the Google Trends topics for a selected category. 

We added these unit tests to check for basic SEO tags.

The tests above make sure the component sets proper canonical URLs, page titles and meta descriptions. 

You could easily extend this list to include other meta tags like meta robots and hreflang tags.

After you write tests like these, you generally need to execute them after you update the app.

Here is how you run them using Jasmine. In Angular, you type the command: ng test

Here is what the output looks like.

As developers add new features to the website or app and then run the tests, they can get immediate feedback when they forget to add important SEO tags or introduce incorrect ones.

Part of your ongoing work as an SEO is to make sure new relevant components are covered by unit tests.

Writing SEO integration tests

Next, let’s review some of the integration tests that I coded for our app so you can see what they look like.

In Angular, we can use Protractor to run end to end tests.

You might be wondering why we need two different tools to run automated tests?

End-to-end tests run exclusively on a web browser by automating the browser so it performs the scripted actions we specify. This is very different from unit testing where we could run just the specific back end/front end code that we are testing.

If we look at our example app’s category topics page, you can see we added end-to-end tests to check for prerendering issues.

The example tests check that our basic SEO tags work correctly after the page is rendered. This is a test that requires loading the page in the browser and wait for the JavaScript code to execute.

One simple check we added was to make sure the key meta tags like title and meta description didn’t come back null after rendering. Another test would be to check the server-side tags and client-side rendered tags are not different as it could cause cloaking issues.

Here is how you run them using Protractor. In Angular, you type the command: ng e2e

Prerendering JavaScript-based sites can lead to SEO issues that are hard to detect in production. Robust integration tests can provide a strong first line of defense.

Continuous integration

I didn’t cover this topic during my talk, but it is worth mention it. Most development teams that write automated tests, also implement a technique called continuous integration.

Continuous integration allows developers to push their code changes to a code repository and have each commit trigger a suite of automated tests. If the tests pass, the code is packaged for release and deployed automatically. But, if any of the tests fail, the packaging and release pipeline is halted.

Some continuous integration tools like CircleCi require you to add a simple test definitions file to your code repository, add the project to their service and they will run all automated tests, including the deployment pipeline, plus include reporting.

As an SEO practitioner, you could ask your dev team to give you access so you can review SEO tests that fail and review SEO test coverage to recommend any missing tests.

Shared responsibilities

Catching SEO errors during development can save companies a lot of money and headache, and it is a shared responsibility between developers and technical SEOs.

I created these two tables to help define some of the different responsibilities for unit tests and integration tests.

Resources to learn more

I used Angular examples, but automated testing is an established discipline in professional development. You can find equivalent tools and processes in most frameworks.

Here are a few to investigate further for your specific dev stack.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

About The Author

Hamlet Batista is CEO and founder of RankSense, an agile SEO platform for online retailers and manufacturers. He holds U.S. patents on innovative SEO technologies, started doing SEO as a successful affiliate marketer back in 2002, and believes great SEO results should not take 6 months.