Búsqueda
Borrar búsqueda
Cerrar búsqueda
Aplicaciones de Google
Menú principal
true

Informe de estado de cobertura del índice

Beta de la nueva versión de Search Console

Con este informe, puedes consultar qué páginas se han indexado y cómo corregir las que no han podido incluirse en el índice. Las diferentes barras del gráfico representan el total de URLs en un estado concreto (válidas, con errores, etc.) tal como las clasifica Google.

ABRIR INFORME DE COBERTURA DEL ÍNDICE

 

Sharing the report

You can share issue details by clicking the Share button on the page. This link grants access only to the current page, plus any validation history pages for this issue, to anyone with the link. It does not grant access to other pages for your resource, or enable the shared user to perform any actions on your property or account. You can revoke the link at any time by disabling sharing for this page.

 

Qué buscar

En una situación ideal, la cantidad de páginas que se han indexado correctamente aumenta a medida que crece tu sitio web.

  • Pueden producirse picos de errores de indexación a causa de cambios en tu plantilla que introduzcan errores nuevos, o bien porque has enviado un sitemap con URLs que no pueden rastrearse (por ejemplo, porque se han bloqueado mediante un archivo robots.txt o el método noindex, o porque se requiere iniciar sesión).
  • Si detectas que disminuye el total de páginas indexadas sin que se indiquen los errores correspondientes, es posible que estés bloqueando el acceso a tus páginas, ya sea mediante un archivo robots.txt, con el método "noindex" o requiriendo autenticación. Si la disminución no se debe a ninguno de estos factores, consulta los motivos por los que se excluyen páginas, ordenados por el número de páginas afectadas, para averiguar qué causa este problema.
  • Si tienes un número considerable de páginas sin indexar que crees que deberían estar en el índice, consulta las URL afectadas y busca indicios de por qué se han excluido. Es posible que estés impidiendo que se rastreen muchas de tus páginas mediante un archivo robots.txt o el método noindex.
¿Cómo se detectan estas URL? Google descubre URLs de muchas maneras distintas; por lo general, las encuentra siguiendo enlaces presentes en las páginas que se rastrean o consultando sitemaps. En algunas ocasiones, estos enlaces no son correctos y pueden provocar errores 404 en tu sitio web; en otras, hay páginas que han dejado de existir. En cualquier caso, una vez que Google tenga conocimiento de una URL, tratará de seguir rastreándola durante un tiempo. Se trata de un comportamiento normal; sin embargo, si no quieres que intente rastrear determinadas páginas, puedes impedir que se indexen, bloquear el acceso a ellas o usar redirecciones 301 (en caso necesario).

Informe de nivel superior

En los informes de nivel superior se muestra el estado de indexación de todas las páginas de tu sitio web que Google ha intentado rastrear, agrupadas por estado y motivo.

Estado

Las páginas pueden tener uno de los siguientes estados generales:

  • Error: no se ha indexado la página. Puedes obtener más información sobre los errores y consultar cómo corregirlos en las descripciones de los tipos de error correspondientes. Deberías resolver estos problemas lo más rápido posible.
  • Advertencia: la página está indexada, o lo estaba hasta hace poco, y tiene problemas que debes conocer.
  • Excluida: no se ha incluido la página en el índice por motivos que están fuera de tu alcance. La página puede estar en proceso de indexación o puede que la hayas excluido intencionadamente (por ejemplo, mediante una directiva noindex), por lo que funciona según lo previsto.
  • Válida: se ha indexado la página.

Motivo

Cada estado (válida, advertencia, error, excluida) puede deberse a un motivo concreto. Los datos de la tabla se agrupan por motivo, y en cada fila pueden incluirse varias URL. Para obtener más información sobre los tipos de estado y saber cómo gestionarlos, consulta las descripciones de tipo de estado que se proporcionan más adelante.

Validación

El estado de un flujo de validación iniciado por un usuario del problema en cuestión. Debes dar prioridad a los problemas cuya validación contenga errores o no se haya iniciado.

Filtro desplegable de descubrimiento de URL

Con el filtro desplegable situado sobre el gráfico, puedes mostrar resultados de indexación según el mecanismo mediante el cual se han descubierto URLs. Existen los siguientes valores:

  • Todas las páginas conocidas (predeterminado): se muestran todas las URL que ha descubierto Google, independientemente del método.
  • Todas las páginas enviadas: se muestran solo las páginas que se han enviado mediante sitemaps, ya sea con Search Console, archivos robots.txt o pings de sitemap.
  • URL de un sitemap concreto: se muestran solo las URL de un sitemap concreto que se haya enviado mediante Search Console. Si se trata de un índice de sitemaps, se muestran las URL de todos los sitemaps incluidos.

Se considera que una URL se ha enviado mediante un sitemap aunque también se haya descubierto a través de otro mecanismo, como el rastreo orgánico desde otra página.

Informe detallado de estado y motivo

Al hacer clic en una fila de la parte superior de la página, se muestran datos de un tipo de estado concreto. En el informe de motivos se facilita la siguiente información:

  • Un gráfico en el que se muestran URL según su estado general (válida, error, advertencia, excluida)
  • Una tabla en la que se muestran URL según el tipo de estado y la fecha del último rastreo

Importante: Si detectas que en una URL se marca un problema que ya has corregido, es posible que lo hicieras después del último rastreo de Google. En estos casos, comprueba la fecha del rastreo más reciente y sigue los pasos correspondientes:

  • Si se ha vuelto a rastrear la URL después de que corrigieras el problema, no se ha podido verificar que esté resuelto. Comprueba y confirma que esté solucionado y espera a que vuelva a rastrearse.
  • Si se ha rastreado la URL antes de que corrigieras el problema, espera a que Google vuelva a rastrear la página, o bien haz clic en "Empezar a solucionar problemas" (si se muestra) para resolverlo con el flujo de gestión de problemas.

Solucionar problemas de páginas

  1. Prueba a encontrar correspondencias entre el total de errores de indexación o de páginas indexadas y el minigráfico de errores concretos; al hacerlo, puedes descubrir qué problemas afectan a la cantidad de errores o páginas indexadas.
  2. Corrige errores:
    1. En la tabla de URL, estas están ordenadas en función de la gravedad del error, de la cantidad de páginas afectadas y de si están en proceso de validación. Te recomendamos que resuelvas los problemas en el orden predeterminado.
    2. Si aumenta el número de errores, busca filas cuyo minigráfico coincida en cierto grado con alguno de los picos de errores del gráfico superior. A continuación, haz clic en la fila en cuestión para obtener más información en el informe detallado, que se describe a continuación.
    3. Al hacer clic en filas de errores, se muestra una página de desglose con más información al respecto (puedes consultar más detalles más adelante). Para saber cómo gestionar un tipo de error concreto, lee su descripción.
    4. Corrige los errores causados por cada motivo y solicita que se validen las correcciones haciendo clic en Validar corrección, en el desglose de cada motivo. Más información sobre la validación
    5. Recibirás notificaciones a medida que avance el proceso de validación. No obstante, puedes consultar su estado al cabo de unos días para ver si ha disminuido el número de errores.
  3. Quita regularmente el filtro de URL excluidas, ordénalas por el número de páginas afectadas y analízalas en busca de problemas.

Motivos de estados

A continuación indicamos los motivos de los estados que pueden aplicarse a cualquier página.

Enviadas y no enviadas

Si en los resultados de indexación se muestra la palabra "Enviado", significa que has pedido explícitamente a Google que incluya las URL en cuestión en el índice mediante un sitemap.

Error


Pages with errors have not been indexed.


Server error (5xx): Your server returned a 500-level error when the page was requested.

Redirect error: The URL was a redirect error. Could be one of the following types: it was a redirect chain that was too long; it was a redirect loop; the redirect URL eventually exceeded the max URL length; there was a bad or empty URL in the redirect chain.

Submitted URL blocked by robots.txt: You submitted this page for indexing, but the page is blocked by robots.txt. Try testing your page using the robots.txt tester.

Submitted URL marked ‘noindex’: You submitted this page for indexing, but the page has a 'noindex' directive either in a meta tag or HTTP response. If you want this page to be indexed, you must remove the tag or HTTP response.

Submitted URL seems to be a Soft 404: You submitted this page for indexing, but the server returned what seems to be a soft 404.

Submitted URL returns unauthorized request (401): You submitted this page for indexing, but Google got a 401 (not authorized) response. Either remove authorization requirements for this page, or else allow Googlebot to access your pages by verifying its identity.

Submitted URL not found (404): You submitted a non-existent URL for indexing.

Submitted URL has crawl issue: You submitted this page for indexing, and Google encountered an unspecified crawling error that doesn't fall into any of the other reasons. Try debugging your page using Fetch as Google.

Warning


Pages with a warning status might require your attention, and may or may not have been indexed, according to the specific result.


Indexed, though blocked by robots.txt: The page was indexed, despite being blocked by robots.txt (Google always respects robots.txt, but this doesn't help if someone else links to it). This is marked as a warning because we're not sure if you intended to block the page from search results. If you do want to block this page, robots.txt is not the correct mechanism to avoid being indexed. To avoid being indexed you should either use 'noindex' or prohibit anonymous access to the page using auth. You can use the robots.txt tester to determine which rule is blocking this page. Because of the robots.txt, any snippet shown for the page will probably be sub-optimal. If you do not want to block this page, update your robots.txt file to unblock your page.

Valid


Pages with a valid status have been indexed.

Submitted and indexed: You submitted the URL for indexing, and it was indexed.

Indexed, not submitted in sitemap: The URL was discovered by Google and indexed. We recommend submitting all important URLs using a sitemap.

Indexed; consider marking as canonical: The URL was indexed. Because it has duplicate URLs, we recommend explicitly marking this URL as canonical.

Excluded


These pages are typically not indexed, but probably for intentional reasons.


Blocked by ‘noindex’ tag: When Google tried to index the page it encountered a 'noindex' directive, and therefore did not index it. If you do not want the page indexed, you have done so correctly. If you do want this page to be indexed, you should remove that 'noindex' directive.

Blocked by page removal tool: The page is currently blocked by a URL removal request. Removal requests are only good for a specified period of time (see the linked documentation). After that period, Googlebot may go back and index the page, even if you do not submit another index request. If you do not want the page to be indexed, use 'noindex', require authorization for the page, or remove the page. If you are a verified site owner, you can use the URL removals tool to see who submitted a URL removal request.

Blocked by robots.txt: This page was blocked to Googlebot with a robots.txt file. You can verify this using the robots.txt tester. Note that this does not mean that the page won't be indexed through some other means. If Google can find other information about this page without loading it, the page could still be indexed (though this is less common). To ensure that a page is not indexed by Google, remove the robots.txt block and use a 'noindex' directive.

Blocked due to unauthorized request (401): The page was blocked to Googlebot by a request for authorization (401 response). If you do want Googlebot to be able to crawl this page, either remove authorization requirements, or allow Googlebot to access your pages by verifying its identity.

Crawl anomaly: An unspecified anomaly occurred when fetching this URL. This could mean a 4xx- or 5xx-level response code; try fetching the page using Fetch as Google to see if it encounters any fetch issues. The page was not indexed.

Crawled - currently not indexed: The page was crawled by Google, but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.

Discovered - currently not indexed: The page was found by Google, but not crawled yet.

Alternate page with proper canonical tag: This page is a duplicate of a page that Google recognizes as canonical, and it correctly points to that canonical page, so nothing for you to do here!

Duplicate page without canonical tag: This page has duplicates, none of which is marked canonical. We think this page is not the canonical one. You should explicitly mark the canonical for this page. To learn which page is the canonical, click the table row to run an info: query for this URL, which should list its canonical page.

Duplicate non-HTML page: A non-HTML page (for example, a PDF file) is a duplicate of another page that Google has marked as canonical. Typically only the canonical URL will be shown in Google Search. If you like, you can specify a canonical page using the Link HTTP header in a response.

Google chose different canonical than user: This URL is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical. Because we consider this page a duplicate, we did not index it; only the canonical page is indexed. We recommend that you explicitly mark this page as a duplicate of the canonical URL. To learn which page is the canonical, click the table row to run an info: query for this URL, which should list its canonical page.

Not found (404): This page returned a 404 error when requested. The URL was discovered by Google without any explicit request to be crawled. Google could have learned of the URL through different ways: for example, another page links to it, or it existed previously and was deleted. Googlebot will probably continue to try this URL for some period of time; there is no way to tell Googlebot to permanently forget a URL, although it will crawl it less and less often. 404 responses are not a problem, if intentional. If your page has moved, use a 301 redirect to the new location. Read here to learn more about how to think about 404 errors on your site.

Page removed because of legal complaint: The page was removed from the index because of a legal complaint.

Page with redirect: The URL is a redirect, and therefore was not added to the index.

Queued for crawling: The page is in the crawling queue; check back in a few days to see if it has been crawled.

Soft 404: The page request returns what we think is a soft 404 response. This means that it returns a user-friendly "not found" message without a corresponding 404 response code. We recommend returning a 404 response code for "not found" pages to prevent indexing of the page.

Submitted URL dropped: You submitted this page for indexing, but it was dropped from the index for an unspecified reason.

Submitted URL not selected as canonical: The URL is one of a set of duplicate URLs without an explicitly marked canonical page. You explicitly asked this URL to be indexed, but because it is a duplicate, and Google thinks that another URL is a better candidate for canonical, Google did not index this URL. Instead, we indexed the canonical that we selected. The difference between this status and "Google chose different canonical than user" is that, in this case, you explicitly requested indexing.

 

About validation

After you fix all instances of a specific issue on your site, you can ask Google to validate your changes. If all known instances are gone, the issue is marked as fixed in the status table and dropped to the bottom of the table. Search Console keeps track independently of the state of the issue and of each instance of the issue. When all instances of the issue are gone, the issue is considered fixed. (For actual states recorded, see Issue validation state and Instance validation state.)

More about issue lifetime...

An issue's lifetime extends from the first time any instance of that issue was detected on your site until 90 days after the last instance was marked as gone from your site. If ninety days pass without any recurrences, the issue is removed from the report history.

The issue's first detected date is the first time the issue was detected during the issue's lifetime, and does not change. Therefore:

  • If all instances of an issue are fixed, but a new instance of the issue occurs 15 days later, the issue is marked as open, and "first detected" date remains the original date.
  • If the same issue occurs 91 days after the last instance was fixed, the previous issue was closed, and so this is recorded as a new issue, with the first detected date set to "today".

Basic validation flow

Here is an overview of the validation process after you click Validate Fix for an issue. This process can take several days, and you will receive progress notifications by email.

  1. When you click Validate Fix, Search Console immediately checks a few pages.
    • If the current instance exists in any of these pages, validation ends, and the validation state remains unchanged.
    • If the sample pages do not have the current error, validation continues with state Started. If validation finds other unrelated issues, these issues are counted against that other issue type and validation continues.
  2. Search Console works through the list of known URLs affected by this issue. Only URLs with known instances of this issue are queued for recrawling, not the whole site. Search Console keeps a record of all URLs checked in the validation history, which can be reached from the issue details page.
  3. When a URL is checked:
    1. If the issue is not found, the instance validation state changes to Passing. If this is the first instance checked after validation has started, the issue validation state changes to Looking good.
    2. If the URL is no longer reachable, the instance validation state changes to Other (which is not an error state).
    3. If the instance is still present, issue state changes to Failed and validation ends. If this is a new page discovered by normal crawling, it is considered another instance of this existing issue.
  4. When all error and warning URLs have been checked and the issue count is 0, the issue state changes to Passed. Important: Even when the number of affected pages drops to 0 and issue state changes to Passed, the original severity label will still be shown (Error or Warning).

Even if you never click "start validation" Google can detect fixed instances of an issue. If Google detects that all instances of an issue have been fixed during its regular crawl, it will change the issue state to "N/A" on the report.

When is an issue considered "fixed" for a URL or item?

An issue is marked as fixed for a URL when either of the following conditions are met:

  • When the URL is crawled and the issue is no longer found on the page. Note that for an AMP tag error, this can mean that you either fixed the tag or that the tag has been removed (if the tag is not required). During a validation attempt, it will be considered as "passed."
  • If the page is not available to Google for any reason (page removed, marked noindex, requires authentication, and so on), the issue will be considered as fixed for that URL. During a validation attempt, it is counted in the "other" validation state.

Revalidation

When you click Revalidate for a failed validation, validation restarts for all failed instances, plus any new instances of this issue discovered through normal crawling.

You should wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.

Instances that have passed validation (marked Passed) or are no longer reachable (marked Other) are not checked again, and are removed from the history when you click Revalidate.

Validation history

You can see the progress of a validation request by clicking the validation details link in the issue details page.

Items in validation history are grouped by URL for the AMP report and Index Status report. In the Jobs report or other structured data reports, items are grouped by the combination of URL + structured data item (as determined by the item's Name value).

Issue validation state

The following validation states apply to a given issue:

  • Not started: There are one or more pages with an instance of this issue that you have never begun a validation attempt for. Next steps:
    1. Click into the issue to learn the details of the error. Inspect the individual pages to see examples of the error on the live page using the AMP Test. (If the AMP Test does not show the error on the page, it is because you fixed the error on the live page after Google found the error and generated this issue report.)
    2. Click "Learn more" on the details page to see the details of the rule that was violated.
    3. Click an example URL row in the table to get details on that specific error.
    4. Fix your pages and then click Validate fix to have Google recrawl your pages. Google will notify you about the progress of the validation. Validation takes anywhere from a few days up to about two weeks, so please be patient. 
  • Started:  You have begun a validation attempt and no remaining instances of the issue have been found yet. Next step: Google will send notifications as validation proceeds, telling you what to do, if necessary.
  • Looking good: You started a validation attempt, and all issue instances that have been checked so far have been fixed. Next step: Nothing to do, but Google will send notifications as validation proceeds, telling you what to do.
  • Passed: All known instances of the issue are gone (or the affected URL is no longer available). You must have clicked "Validate fix" to get to this state (if instances disappeared without you requesting validation, state would change to N/A). Next step: Nothing more to do.
  • N/A: Google found that the issue was fixed on all URLs, even though you never started a validation attempt. Next step: Nothing more to do.
  • Failed: A certain threshold of pages still contain this issue, after you clicked "Validate." Next steps: Fix the issue and revalidate.

Instance validation state

After validation has been requested, every known issue instance is assigned one of the following validation states for a specific issue (states Passed and Other not used in Index Status report):

  • Pending validation: Queued for validation. The last time Google looked, this issue instance existed.
  • Passed: Google checked for the issue instance and it no longer exists. Can reach this state only if you explicitly clicked Validate for this issue instance.
  • Failed: Google checked for the issue instance and it's still there. Can reach this state only if you explicitly clicked Validate for this issue instance.
  • Other: Google couldn't reach the URL hosting the instance, or (for structured data) couldn't find the item on the page any more. Considered equivalent to Passed.

Note that the same URL can have different states for different issues; For example, if a single page has both issue X and issue Y, issue X can be in validation state Passed and issue Y on the same page can be in validation state Pending.

 

Problemas conocidos

A continuación se indican los problemas que se han detectado en esta beta de la nueva versión de Search Console. No es necesario que nos informes de ninguno de ellos, pero sí nos gustaría recibir tus comentarios sobre funciones u otros problemas que detectes. Puedes enviárnoslos con la opción de comentarios de la barra de navegación.

  • Los datos de indexación no se actualizan cada día, por lo que pueden tener varios días de retraso. Además, algunos puntos de datos se interpolan.
  • En los gráficos debería incluirse información de los últimos 90 días, aunque es posible que en estos momentos se muestren menos datos. 
  • En el filtro desplegable de sitemaps se incluyen solo los sitemaps que se han enviado mediante Search Console o directivas robots.txt.
  • Estamos perfeccionando la lista de estados, por lo que es posible que cambie más adelante. Por ejemplo:
    • En los elementos que se consideran errores se incluyen diferentes tipos de respuesta (4xx/5xx).
    • Puedes ignorar los elementos que se hayan marcado con "Retirada por motivos no especificados" u "Otros".
  • Por ahora, al hacer clic en una fila de motivo concreta, se te dirige a herramientas de la versión antigua de Search Console; esperamos mejorarlo de cara al futuro.
  • Seguimos trabajando para mejorar la versión móvil.
  • Todavía no se admiten conjuntos de propiedades ni propiedades de aplicaciones móviles.
¿Te ha sido útil este artículo?
¿Cómo podemos mejorar esta página?
false