Col1, Col2 y ColN en la función QUERY de Google Sheets no hacen referencia a las columnas A, B, C de tu hoja - hacen referencia a la 1.ª, 2.ª y N.ª columna del rango que le pasas a la función. Si tu rango es C1:F100, entonces Col1 es la columna C, Col2 es D, Col3 es E y Col4 es F. Eso es todo el concepto. A partir de abril de 2026, este malentendido es responsable de más errores #VALUE! y errores de parseo en fórmulas QUERY que cualquier otro problema de sintaxis.
La función QUERY utiliza el lenguaje de consulta de la API de Visualización de Google, que soporta 11 cláusulas distintas (select, where, group by, pivot, order by, limit, offset, label, format, options, skipping). La notación ColN es la forma en que ese lenguaje identifica columnas cuando no puede usar encabezados con nombre - y entender el porqué importa más que memorizar la sintaxis.
Cómo mapear Col1 y Col2 a columnas reales en tu hoja
El número de ColN representa su posición contando de izquierda a derecha desde la primera columna de tu rango. Así es como se traduce para distintos rangos:
| Rango | Col1 | Col2 | Col3 | Col4 | Col5 |
|---|---|---|---|---|---|
A:D | A | B | C | D | - |
B:E | B | C | D | E | - |
C:F | C | D | E | F | - |
Ingresos!D:H | D | E | F | G | H |
Entonces =QUERY(C1:F100, "SELECT Col1, Col3 WHERE Col2 > 1000") selecciona las columnas C y E, filtradas por la columna D. Si escribes SELECT C, E WHERE D > 1000, QUERY lanza un error de parseo - no acepta letras de columna en ese contexto.
La confusión se agrava porque la documentación de =QUERY en la ayuda de Google Sheets usa ejemplos con letras de columna y ejemplos con ColN en distintos lugares, sin aclarar siempre cuál sintaxis aplica en cada caso.
Por qué la sintaxis ColN se rompe cuando mueves columnas
Inserta una columna antes de tu rango y cada referencia ColN dentro de tu consulta se desplaza en silencio. La fórmula no da error - simplemente devuelve datos incorrectos.
Imagina que tu fórmula es =QUERY(B:E, "SELECT Col1, Col2, Col4 WHERE Col3 = 'Activo'"). Está leyendo las columnas B, C, E donde D es "Activo." Alguien inserta una columna en C para agregar un campo de notas. Ahora tu rango B:E captura la nueva columna C, tu antigua columna C pasa a ser Col3, y tu antigua columna D (el filtro "Activo") es Col4. La fórmula sigue ejecutándose. Solo que está respondiendo una pregunta diferente a la que escribiste.
Por eso bloquear rangos con límites explícitos (B2:E5000 en lugar de B:E) solo ayuda en parte. La solución real es usar rangos con nombre o documentar el mapa de columnas en un comentario visible. Según la referencia del lenguaje de consulta de la API de Visualización de Google, los índices ColN siempre se evalúan en el momento de ejecución de la consulta, en relación con la tabla de datos que se le pasa - no hay vinculación estática.
Usar criterios dinámicos en QUERY con la sintaxis Col
Las cláusulas WHERE con valores fijos se vuelven obsoletas con el tiempo. Los trimestres terminan, los filtros cambian, alguien olvida actualizar la fórmula. El patrón que funciona es vincular los criterios de filtro a una celda:
=QUERY(B2:F5000,
"SELECT Col1, Col3, Col5
WHERE Col4 = date '"&TEXT(A2,"yyyy-mm-dd")&"'",
1)
El TEXT(A2,"yyyy-mm-dd") fuerza la fecha al formato exacto que espera el parser de QUERY. Usa cualquier otro formato y obtendrás un error de tipo. Esto no es una particularidad de QUERY - está definido en la especificación de la API de Visualización: los literales de fecha deben seguir el estándar ISO 8601 (yyyy-MM-dd), tal como lo documenta la referencia del lenguaje de consulta de Google.
Para filtros de texto, el mismo principio aplica:
=QUERY(B2:F5000,
"SELECT Col1, Col3, Col5
WHERE Col2 = '"&A1&"'",
1)
Si omites las comillas internas, QUERY intenta evaluar el valor de la celda como un nombre de columna. Si las incluyes, lo trata como una cadena de texto literal. El 1 al final le indica a QUERY que la primera fila es un encabezado - si lo omites, QUERY trata tu fila de encabezados como datos.
Rangos combinados y el reinicio de ColN
Cuando combinas dos rangos con llaves - {Hoja1!A:D, Hoja2!E:G} - QUERY trata el resultado como una sola tabla plana. ColN comienza desde Col1 en la columna más a la izquierda del rango combinado. La columna E de Hoja2 se convierte en Col5 (o donde quede en la tabla fusionada), no en Col1.
Esto es clave en cruces de tablas. Un patrón común en reportes para directivos o inversionistas:
=QUERY(
{Cuentas!A2:C, IFERROR(
VLOOKUP(Cuentas!A2:A, Negocios!A:D, {2,3,4}, 0),
{"","",""})},
"SELECT Col1, Col2, Col4, Col5, Col6
WHERE Col3 = 'Enterprise'
ORDER BY Col6 DESC",
0
)
El rango combinado tiene 6 columnas en total: 3 de Cuentas (A, B, C → Col1, Col2, Col3) y 3 del resultado del VLOOKUP (→ Col4, Col5, Col6). El IFERROR alrededor del VLOOKUP completa con cadenas vacías las filas de Cuentas que no tienen un Negocio asociado - algo que en cualquier dataset real cubre aproximadamente entre el 12% y el 15% de las filas a las pocas semanas de estar en producción.
El 0 al final (conteo de filas de encabezado) es intencional aquí, ya que estamos construyendo el rango de forma programática y no tomándolo de una hoja que tenga encabezados en la fila 1.
Manejo de la sintaxis ColN en datasets de gran volumen
QUERY se ejecuta completamente en el navegador, sobre la infraestructura de Google. En rangos con 4,800 números y 200 cadenas de texto, es prácticamente instantáneo. En 50,000 filas con múltiples cruces de tablas anidados, la demora de recálculo se vuelve real - especialmente si la hoja recalcula en cada edición. Google Sheets tiene un límite de 10 millones de celdas por libro, y el timeout de ejecución de 30 segundos para QUERY aplica antes de alcanzar ese límite.
Algunas cosas que realmente ayudan a escala:
Delimitar el rango. B2:F (abierto) obliga a QUERY a escanear cada fila hasta el límite de filas. B2:F5000 lo acota. Si tu dataset crece más allá de ese límite obtendrás resultados truncados, pero para la mayoría de los dashboards operativos un rango acotado es un buen intercambio entre riesgo de exactitud y velocidad.
Ordenar los filtros por selectividad. Pon primero la cláusula WHERE más selectiva. WHERE Col3 = 'Cerrado Ganado' AND Col5 > DATE '2026-01-01' corre más rápido que las mismas condiciones invertidas, si Col3 elimina el 90% de las filas.
Delegar a una herramienta que no recalcule en el navegador. Si consultas regularmente contra un CSV exportado de 40,000 filas o una conexión a PostgreSQL en vivo, la integración de ModelMonkey con DuckDB maneja eso sin el overhead de recálculo - escribes SQL, los resultados aparecen en la hoja, sin necesidad de mapear ColN.
Sintaxis ColN en QUERY vs. FILTER: cuándo usar cuál
Ambas funciones filtran filas, pero responden preguntas distintas.
| Situación | Usa QUERY | Usa FILTER |
|---|---|---|
| Necesitas seleccionar columnas (SELECT) | Sí | No |
| Necesitas agregación (GROUP BY, SUM) | Sí | No |
| Filtrar por múltiples condiciones | Cualquiera | Cualquiera |
| Output de array dinámico en Sheets moderno | Cualquiera | Sí (más limpio) |
| Manejo de fila de encabezado | Integrado (3.er arg) | Manual |
| Ordenamiento complejo (ORDER BY) | Sí | No |
| Cruce de rangos combinados | Sí | Complicado |
FILTER es más simple para selección básica de filas. QUERY es la opción correcta en cuanto necesitas transformar o agregar datos - seleccionar 3 de 8 columnas, pivotar categorías o agrupar por mes.
Como señala la documentación de funciones de Google Sheets, QUERY "ejecuta una consulta del lenguaje de consulta de la API de Visualización de Google sobre los datos" - lo que significa que es un motor de consultas completo, no simplemente una capa de filtrado.
Preguntas frecuentes sobre Col1, Col2 y ColN en QUERY
¿Cuál es la diferencia entre Col1 y la columna A en QUERY de Google Sheets?
Col1 no es la columna A de tu hoja de cálculo - es la primera columna del rango que le pasas a QUERY. Si tu rango empieza en D2, entonces Col1 corresponde a la columna D. La columna A solo sería Col1 si tu rango comenzara en A. Esta distinción es la fuente más común de errores #VALUE! en fórmulas QUERY: quien escribe la fórmula asume que Col1 siempre es A, mueve el rango, y la consulta empieza a leer columnas equivocadas sin arrojar ningún error visible.
¿Por qué QUERY lanza error de parseo cuando uso letras de columna en lugar de ColN?
Porque el lenguaje de consulta de la API de Visualización de Google - que es el motor que usa QUERY internamente - no reconoce las letras de columna de Google Sheets como identificadores válidos. Ese lenguaje opera sobre una tabla de datos abstracta, no sobre una hoja de cálculo. Dentro de la cadena de consulta, los únicos identificadores de columna válidos son Col1, Col2, etc. Escribir SELECT A, C WHERE B > 1000 produce un error de parseo inmediato porque A, B y C no existen como identificadores en ese contexto.
¿Cómo uso la sintaxis ColN con rangos que abarcan varias hojas?
Cuando combinas rangos de varias hojas con llaves - por ejemplo {Hoja1!A2:C, Hoja2!D2:F} - QUERY los trata como una sola tabla plana y la numeración ColN comienza desde el extremo izquierdo del conjunto combinado. En ese ejemplo, las tres columnas de Hoja1 serían Col1, Col2 y Col3, y las tres columnas de Hoja2 serían Col4, Col5 y Col6. La clave es contar las columnas de izquierda a derecha en el orden en que aparecen dentro de las llaves, sin importar en qué hoja originalmente viven. Un error frecuente es asumir que cada hoja reinicia el conteo desde Col1.
¿Qué pasa con ColN si mi rango tiene columnas vacías en el medio?
Las columnas vacías cuentan igual. Si tu rango es A:E y la columna C no tiene datos, Col3 sigue siendo la columna C - simplemente devolverá valores vacíos cuando la selecciones o uses en un filtro. QUERY no colapsa ni ignora columnas vacías al asignar los índices ColN.
¿Puedo combinar ColN con la cláusula LABEL para mostrar nombres legibles en los encabezados?
Sí, y es una práctica recomendada cuando compartes reportes. La cláusula LABEL te permite renombrar cualquier columna en el resultado sin cambiar la lógica de la consulta: SELECT Col1, Col3, Col5 LABEL Col1 'Empresa', Col3 'Ingreso Mensual', Col5 'Estado'. Esto es especialmente útil en dashboards para directivos o en reportes que se exportan a PDF, donde los encabezados Col1, Col3 no tienen ningún significado para el lector final.