Cada vez que Microsoft anuncia algo con la palabra "HTML" y la palabra "SharePoint" en la misma frase, alguien en el equipo de comunicación interna sonríe. Por fin, piensa, vamos a poder subir la página que diseñó la agencia, con nuestras fuentes, nuestros colores, sin pelear con web parts. Y alguien en el equipo técnico se pone nervioso, porque ya vio esa película.
Esta semana la película volvió. Microsoft publicó en el Message Center que SharePoint Online va a aceptar páginas HTML como un tipo de página más, al lado de las ASPX de siempre. Se pueden crear con Copilot, subir desde otra herramienta, editar y publicar.
Suena a revolución. Es otra cosa, más modesta y más útil de lo que parece. Vamos por partes.
Qué llega y cuándo
El anuncio es el MC1479517, asociado al ítem 569208 del roadmap. La vista previa pública arranca a comienzos de octubre de 2026 y la disponibilidad general mundial se despliega entre mediados de noviembre y fines de diciembre.
En la práctica, el autor de páginas gana tres caminos nuevos: crear una página HTML desde el menú + New de un sitio, pedírsela a Copilot desde el botón flotante, o subir un archivo .html (o una carpeta completa con sus recursos) directamente a la biblioteca Site Pages. Las páginas quedan ahí, con los mismos permisos y la misma gobernanza que ya tiene el sitio.
Qué hace falta para usarlo
La lista de requisitos es corta, y tiene un par de sorpresas:
- Un interruptor por sitio. Antes de que alguien pueda subir HTML, un propietario del sitio tiene que entrar a Site Pages, abrir File types y activar Allow HTML files. Sin eso, la opción no aparece.
- Copilot solo para crear con Copilot. La licencia de Microsoft 365 Copilot es necesaria para usar la pantalla de creación asistida y el chat de edición. Subir un HTML propio, editar el texto, publicar, compartir y ver la página no requieren licencia.
- Diez megas por archivo. Es el tamaño máximo de un HTML en Site Pages.
- Lista blanca para links externos. Para que un enlace a otro dominio o a otro tenant funcione, el administrador del sitio tiene que agregar el dominio en HTML Field Security.
- Sin interruptor global. Según la documentación de Microsoft, la función no se puede desactivar ni restringir a nivel de tenant. El único freno es el toggle de cada sitio.
Ese último punto merece una pausa. Si tu organización tiene cientos de sitios, la decisión de quién puede publicar HTML queda distribuida entre cientos de propietarios. Para un equipo de gobernanza, eso es una conversación que conviene tener antes de noviembre, no después.
Una habitación sellada
Acá está la parte que cambia todas las expectativas. SharePoint no sirve ese HTML como serviría una página web. Lo encierra en un iframe con sandbox y una política de seguridad de contenido (CSP) muy estricta, aislado del encabezado, la navegación y el resto del sitio.
Dentro de esa habitación, el JavaScript corre, pero no puede salir. No hace fetch, no llama APIs externas, no accede a localStorage. Denis Molodtsov, arquitecto de Microsoft 365, desarmó el visor con las herramientas del navegador durante la etapa de Targeted release y documentó lo que no está en ninguna página oficial: el código dentro del iframe no sabe quién es el usuario, no tiene contexto de página y no puede llamar ni a la REST API de SharePoint ni a Microsoft Graph.
Tampoco puede embeber otros iframes, así que un tablero de Power BI, un formulario de Forms o un video de Stream quedan afuera. Y todos los enlaces, sin importar el atributo target, se abren en una pestaña nueva.
Microsoft no construyó un lugar para correr código. Construyó un visor para un formato nuevo, igual que ya existía uno para PDF.
Hay un detalle a validar cuando llegue a tu tenant. La documentación oficial, actualizada el 30 de septiembre, dice que el sandbox admite cinco librerías servidas desde un CDN de Microsoft: Chart.js, Mermaid, React, Fluent UI y Babylon. En las pruebas de agosto, antes de la vista previa, ninguna librería externa cargaba. Es probable que eso sea justamente lo que cambió, pero conviene confirmarlo con un archivo de prueba.
Datos "en vivo" que son una foto
La función más interesante es la de datos conectados. Copilot puede generar un HTML que muestra el contenido de una lista de SharePoint, un Excel o un CSV, y que se actualiza cada vez que se abre.
El truco es que el HTML nunca busca los datos. Declara en un bloque de configuración qué fuentes necesita, y es la página de SharePoint, afuera del iframe, la que trae las filas y se las entrega antes de que el archivo se dibuje. Hasta 100 mil filas por fuente, todas las columnas incluidas, sin paginación ni consultas posteriores.
Filtrar, ordenar y buscar funciona, porque ocurre en memoria. Escribir de vuelta, no. Actualizar significa recargar todo desde cero. Es una foto que se vuelve a sacar cada vez que alguien abre la página, no una conexión.
Páginas HTML frente a SPFx
Para quien construye portales, la pregunta inevitable es si esto reemplaza al SharePoint Framework. La comparación lo responde sola:
| Página HTML | Web part SPFx | |
|---|---|---|
| Despliegue | Subir un archivo | Paquete en el App Catalog |
| Quién la crea | Cualquier autor, o Copilot | Un desarrollador |
| Contexto del usuario | Ninguno | Completo (identidad, sitio, idioma) |
| REST y Graph | Bloqueados | Disponibles con permisos aprobados |
| Datos | Listas, Excel, CSV, solo lectura | Cualquier API, lectura y escritura |
| Llamadas externas | Bloqueadas | Permitidas vía orígenes de confianza |
| Navegación | Siempre pestaña nueva | Normal |
| Tema del sitio | No se hereda en HTML subido | Se hereda |
| Composición en página | Una página entera, aislada | Pieza combinable con otros web parts |
| Licencia para crear | Copilot si se usa Copilot | Ninguna adicional |
Lo que más pesa en un proyecto real está en las filas del medio. Un indicador que respeta la seguridad del usuario, un formulario que guarda en una lista, una consulta a la Execute Queries API de Power BI (como contamos acá), un menú que navega: todo eso sigue siendo territorio de SPFx.
Cinco alertas antes de entusiasmarse
- No sirve para armar una intranet. Si cada clic abre una pestaña nueva, un portal hecho de páginas HTML se vuelve un laberinto. Para portadas, menús y páginas de área, las páginas modernas siguen siendo el camino.
- El HTML que hizo la agencia probablemente no funcione tal cual. Hojas de estilo externas, fuentes web, scripts de terceros e imágenes por URL chocan con el sandbox. Habrá que embeber recursos o rehacer partes.
- Los datos no se indexan. El buscador ve el archivo, pero no las filas que se inyectan al abrirlo. Nadie va a encontrar esa página buscando algo que aparece en su tabla.
- Copiar no es migrar. Las referencias a listas viven dentro del propio HTML. Un archivo copiado a otro sitio sigue leyendo la lista original, y las herramientas de migración no saben corregirlo.
- La gobernanza queda en manos de cada sitio. Sin control a nivel tenant, conviene definir desde ya una política sobre qué sitios habilitan HTML y quién revisa lo que se publica.
Dónde sí brilla
Dicho todo esto, la función tiene un lugar claro y valioso. Es el formato perfecto para que Copilot entregue un trabajo terminado: un informe de estado de proyecto, una guía visual de marca, un tablero de lectura sobre una lista, un resumen ejecutivo con filtros. Algo que se pide en lenguaje natural, se revisa, se ajusta con otro pedido y se comparte.
Y tiene una ventaja económica que pocos mencionan: quien mira la página no necesita licencia de Copilot. Unas pocas licencias de autoría pueden alimentar a toda una organización de lectores.
El punto
Las páginas HTML no son una puerta trasera para desarrollar en SharePoint sin SPFx. Son un tipo de archivo nuevo, pensado para que la IA tenga un formato que puede escribir de una sola vez. Para reportes de lectura, es una gran noticia. Para portales, aplicaciones e integraciones, la arquitectura no cambia.
La clave es no confundir las dos cosas al planificar. Usar HTML donde basta con mostrar, y SPFx donde hace falta saber quién mira, conectar sistemas o guardar algo.
¿Tu organización está evaluando cómo encajan las páginas HTML en su intranet o portal en SharePoint? Conversemos en macareno.net.
Fuentes
- Create, upload, edit, and publish HTML pages in SharePoint, Microsoft Support
- SharePoint: HTML pages (MC1479517), M365 Admin
- MC1479517 SharePoint HTML pages, PUPUWEB
- SharePoint gets HTML pages support, Erik365
- SharePoint HTML pages, what they can and cannot do, Denis Molodtsov
- What's New in Copilot in SharePoint: August 2026, Microsoft Tech Community