Using Google Search Console to manage ‘search enhancement’ validation errors and employing the API

Wrapping up our series on Google Search Console we’ll look at reporting features that deal with front-end markup errors and some data management options. Note that what we’re discussing here are Google “Search Enhancements” validation errors, so when it comes to validating HTML and CSS you’ll need to look elsewhere.

Search enhancements

We covered page-level error reporting using the URL Inspection Tool. The Enhancements section details site-wide warnings and error reporting.

Mobile Usability, AMP-HTML, and Rich results information can be found when the corresponding markup is detected. Google has a small number of dedicated validation services and it’s nice to see some replication of these in Google Search Console. Notably missing, however, are Lighthouse findings.

In the Mobile Usability report, you can view errors that aren’t necessarily validation errors but, for some reason, Google has flagged them as being mobile-unfriendly.

Ideally, you won’t see any errors, but keep in mind that perfectly valid markup can be reported as having Mobile Usability “errors.” It’s important to know the difference for relating Mobile Usability feedback to developers. The errors shown above indicate totally valid markup for a page that is otherwise not mobile-friendly.

On the other hand, when it comes to AMP and Structured Data reporting, validation errors will broadly affect your appearance in Google Search — not just mobile search. Charting here is practically unnecessary; you will want to see the data table with its details. It’s common to find only a fraction of your indexed pages in reporting. Google API documentation refers to the fraction as a “samples list.” These data serve as a hint that pages where such markup has been detected could possibly qualify to power corresponding Google “Search Enhancement” features.

[related-posts section_title=”Catch up with previous installments of the Google Search Console series” sel_ids=”311288,311790″ ml_ids=”” mtt_ids=”” post_list_limit=”4″]

Security & manual actions

The most vital issues you would likely ever see reported in Google Search Console are found in the Security & Manual Actions section. You’ll want to be notified to correct these issues as soon as possible, as they could cause you to be removed from appearing in search altogether until they are remedied and Google registers your site as safe again. (See Search Engine Land’s Guide to Google Penalties for all the details.)

Links

Google is well-known for being a search engine that deeply analyzes the Web, beginning with the voluminous hypertext links among URLs. Although it’s generally true that links are important, it’s too simple to presume a high link count will always boost your rankings. Even when you rightly avoid buying links for the purpose of artificial ranking, you’ll likely find plenty of link cruft in your GSC Links report because the link building economy surrounding Google is so massive.

Downloads & GSC API

Downloads from the Google Search Console are going to be woefully inadequate for all but individual practitioner use. Select your date range for up to 16 months worth of history and download in CSV or Google Spreadsheet format.

A quick CSV can be used for importing to Excel, where it can be marked up as a deliverable for a stakeholder’s specific purpose. Beyond this type of application, you’re not likely to make much more use of downloads as you already have the Search Console charts and data table at your disposal. You’re more likely to graduate to using Google’s Search Console Data Studio connector.

For more advanced users, the Search Console can still be a great data resource, but it’s much more practical to do certain things — such as keeping track of multiple accounts for important information — if you’re pulling all the data into a business intelligence dashboard or otherwise incorporating it programmatically.

Google Search Console API v3

When possible, it’s preferable to write applications for these more advanced purposes, and using Google Search Console API v3 can save you leg work. The API Explorer can be used in combination with an OAuth 2.0 authenticated browser so that a set of query methods allow you to explore using buttons, check-boxes, and fields.

The API Explorer lets you produce JSON responses, including error messages, without needing to set up a separate Google API Console Security Key. You will need a Key for programmatic access to Google’s APIs.

The Web-facing Explorer generates REST application POST URLs for retrieving JSON responses meant to help you prepare larger applications. You’ll want to keep the v3 API documentation handy. Below find a list of the methods implemented with the Explorer User Interface.

It’s nice that the Explorer produces the POST request generated from executing your query. That makes it a snap to emulate using curl to retrieve JSON from the command line, and ultimately you’ll want to do so programmatically. Once you’ve got the API Key for authenticating your query, you can write POST request URLs with the curl utility, or write them dynamically into a host application.

Client libraries

For a project that requires integration with larger applications such as with a BI dashboard, Google provides example Python (and Java) “Hello world!” sample applications you can begin practicing with from your command line once the Python (or Java) client is installed. Clone a sample application, insert your Key, and modify code to get your project started.

Beyond officially listed client libraries, a quick search may yield what you need. I was able to locate a CRAN distributed R package that has recently been updated to use the current v3 API. Armed with both Python and R references the Data Scientist in you should be all set and ready to go. Furthermore, since the v3 API is a RESTful resource, with your API Key handy you can use practically any language you want.