Search
Clear search
Close search
Google apps
Main menu
true

Use Fetch as Google for apps

Test if Google can crawl your app

After you have enabled HTTP URL support in your app, use the Fetch as Google tool as a simple real-time test to see whether Google can index and render your app pages correctly without having to wait for Google's normal crawl cycle. This test is not definitive; see the test result caveats to learn how to handle errors.

Open Fetch as Google for apps

Run a fetch

Fetch as Google reports only a subset of the errors from the Crawl Status report, so use it for a quick crawlability test for an app page rather than a comprehensive quality check.

  1. Enter a URL to your app in the fetch URL textbox. Compose a URL using values from the app manifest. For example, if your manifest specifies the following values:
    <data android:scheme="http"
          android:host="example.com"
          pathPrefix="/a/b" />
    you might specify a URL as "http://example.com/a/b/mypage". Read more about intent filters for HTTP URLs.
  2. [Optional] Choose a version of the app to fetch from. You can fetch the page from either the current version on Google Play (default) or from an APK that you upload here. Search Console stores previously uploaded versions, and enables you to fetch against any of them. Versions uploaded here are not shared with Google Play, may be deleted from time to time, and are visible to all property owners and users. 
  3. [OptionalChoose a device language setting that Googlebot uses when fetching the page.
  4. Click Fetch to start the request. A fetch takes time; your request will be added to the request history table when you click Fetch. The request row will indicate the progress and success or failure of the request in the Status column. Fetch as Google for apps uses the Google Smartphone user agent to request resources.
  5. Understand the fetch status. When the fetch status is complete (anything other than "Pending"), you will see a fetch status. See Understand the fetch status to learn how to interpret this overall status.
  6. Interpret the results. Click the fetch result row to learn more about the results. See Examine fetch data and fix your errors to learn how to interpret to your fetch results.

Fetch history table

The bottom half of the tool shows a history of your fetch requests, including any requests still in progress. As soon as you run a request, it will be added to the history. Multiple requests to the same page will be stored independently.

You can examine previous fetches by clicking them in the fetch history. Past fetch requests are saved with their returned data for future reference.

Understand the fetch status

This tool is a rough test of a page's crawlability; however, any errors that it reports are not necessarily important or guaranteed to occur during an actual crawl attempt. For example, partial fetch errors might be a result of a timeout encountered by the tool that won't happen to the actual crawler, or a blocked resource might not be important. Read the information below carefully for your error type to decide whether the error is important for your page.

If you want to see what errors actually occurred during an app crawl, see the Crawl Status report.

The Status column of the fetch history indicates two things: whether the fetch request has completed, and whether any errors were encountered in the fetch. Fetch times are recorded in Pacific Standard Time (UTC -0800). Once a fetch has completed, you can click the row for more information.

The following fetch statuses can be reported:

Complete
The request completed with no errors. The test does not check for content mismatches, back button violations, or other more complex error types, but the page should be free of any errors listed in the list below.
Partial
The request completed, but there were a few non-critical errors, such as blocked resources on the page. Some of these errors might occur in the tool only, and not in the actual crawl. See the error explanations for more information.
Internal error
An error occurred with Google's fetching engine. Possible reasons include that your APK has an android:minSdkVersion value more than 17, or that your app is unable to run on x86 hardware. This error might occur in the tool only, and not in the actual crawl. If you see a consistent internal error, this is a good indication that the error is real, and not a problem with the test.
URI not supported
The specified URI did not work because it was improperly specified or not present in the app manifest. Examine the URI that you submitted against your app's manifest to find out what went wrong, and upload a new APK. Read more about the manifest syntax here. Note that it can take up to a day for your updates to take effect. This error test is accurate in the Fetch as Google tool, so you must fix your app for it to be crawled by Google.
APK not found
The APK does not exist in the Google Play store, or it has been submitted or updated too recently for it to be found or refreshed. It can take up to a day for new uploads or updates to take effect. This error test is accurate in the Fetch as Google tool, so you must fix your app for it to be crawled by Google.

Examine fetch data and fix your errors

When a fetch finishes, the history table will show the success or failure of that request.

  1. Click a fetch in the table for details about the fetch. If there were no errors or only a few blocked resources, you will see a screenshot of how Googlebot (Google's user agent) sees the app page, and any suggested next steps.
  2. If you have implemented the App Indexing API, the fetch details page also includes information returned by the API when the page was requested. API information includes the page title, page description, app URL and corresponding web page URL. Learn more about the App Indexing API.
  3. If there were fetch errors, you will see instructions on how to fix your errors. Some fetch errors might not occur in an actual index attempt, which is more robust then the Fetch as Google tool; see the error description to learn the degree of importance and verification methods for each error type.

Handle resource fetch errors

If your fetch was only partially successful, you will see a list of errors on the bottom of the fetch details page. These errors all concern resources on the page (images, style sheets, and so on).

Reliability of the resource fetch error: The Fetch as Google for Apps tool is a best attempt at a real-time test, but it can return resource fetch errors that will not occur during an actual index attempt. The actual Google index can be more robust than this tool. However, if an error is not encountered by the tool, it will not be encountered by the actual crawler.

To verify these errors, test the page using either ADB or the QR code shown in the Crawl Status report error dialog box, and verify the presence or absence of the resource.

Impact if true: If the unreachable resource is important to understanding the page content, it can affect usability of the page, or cause a content mismatch error later.

Mitigation: To avoid any negative effect of the missing resource, either make the resource available to Googlebot, or implement the App Indexing API.

Error list

 

Status Explanation Notes and next steps

Not found

The resource could not be found (404 or 410 HTTP response codes).

This error indicates that you might see the HTTP 404 error code when you access your page using a web browser.

Not authorized

Googlebot isn't authorized to access the page (for example, if the page requires a password).

This error indicates that you might see the HTTP 403 error code when you access your page using a web browser.

DNS not found

Google couldn’t retrieve the resource because the domain name wasn’t found.

Make sure that you typed in your domain name properly (for example, www.example.com) so that Google can find your site server.

Blocked

The resource's host is blocking access to Googlebot by means of a robots.txt file.

This error is a common problem that you can fix by updating your robots.txt file. If your property address is at the root domain level (for example, www.example.com, not www.example.com/my_site/), you can use the robots.txt Tester tool to diagnose why the URL is blocked from Google.

Unreachable robots.txt

Googlebot can’t reach the resource host's robots.txt file. When that happens, Google avoids loading any resources from that host.

To resolve this issue, read our Help Center articles on how to create and test robots.txt files.

Unreachable

The resource host either took too long to reply or refused the request.

Check to see that your server is up and running.

Temporarily unreachable

1) Fetch as Google can’t currently fetch your URL because the server took too long to reply.

OR

2) Fetch as Google cancelled your fetch because too many consecutive requests were made to the server for different URIs.

Note the URL is not unreachable for all of Google; it is just unreachable for the Fetch as Google simulation tool.

Error

An unspecified error prevented Google from completing the fetch.

If this error happens again, we ask that you contact Search Console product support.

Next steps

Was this article helpful?
How can we improve it?