Los generadores de sitios estáticos (SSG) como Jekyll, Hugo, Astro y Eleventy consumen archivos Markdown para construir sitios web. Si su equipo de contenido escribe en Word, convertir ese contenido a Markdown es el primer paso crítico. Esta guía abarca la totalidad de Word al sitio estático flujo de trabajo.
El flujo de trabajo principal
Word (.docx) → Markdown (.md) → SSG build → HTML websiteCada flecha es una transformación:
- WordToMD convertidos .docx → .md
- Su sistema de construcción SSG lee .md y genera HTML
- Una CDN o plataforma de alojamiento sirve el HTML
La adición de contenido
Los generadores de sitio estáticos requieren El frente de YAML en la parte superior de cada archivo Markdown. Después de la conversión con WordToMD, añadir un bloque de material delantero antes del contenido:
Jekyll / Diecisiete
---
layout: post
title: "Your Document Title"
date: 2026-05-25
categories: [tutorial, documentation]
tags: [word, markdown]
permalink: /blog/your-document/
---¿ Qué es eso ?
---
title: "Your Document Title"
date: 2026-05-25
draft: false
tags: ["tutorial", "documentation"]
slug: "your-document"
---El nombre de la empresa
---
title: "Your Document Title"
date: 2026-05-25
description: "A brief description for SEO."
tags: ["tutorial", "documentation"]
draft: false
---Organización del archivo
Los SSG esperan archivos de contenido en directorios específicos:
| SSG | Directorio de publicaciones de blogs |
|---|---|
| ¿Qué es eso? | _posts/ (nombre del archivo: YYYY-MM-DD-slug.md) |
| ¿ Qué es eso ? | content/posts/ |
| El nombre de la empresa | src/content/blog/ |
| Diecinueve años | Cualquier directorio que haya configurado |
| Next.js | content/ or posts/ (depende de la configuración) |
Coincide con la convención de nombres de archivo de su SSG. Jekyll es el más estricto: 2026-05-25-word-to-static-site.md.
Títulos y estructura del contenido
Visualización de los SSG # Heading 1 como el título principal de la página. Desde el title El campo frontmatter ya define el título de la página, use H2 (##) como su título de contenido de nivel superior y evitar H1 en el cuerpo.
Antes de la conversión, compruebe que su documento de Word utiliza el encabezado 1 sólo para el título del documento, y el encabezado 2 para las secciones principales. No se puede hacer. Markdown Guía de encabezados para los detalles.
Imágenes en sitios estáticos
Las imágenes de los documentos Word deben ser:
- Exportado desde Word (Guardar como → Página Web copia imágenes a una carpeta)
- Colocado en el directorio de activos estáticos de su SSG (e.g,
public/images/en el caso de Astro/Next.js,assets/images/para Jekyll) - Se refiere en Markdown:
Las tablas
Las tablas Word se convierten en GFM a través de la sintaxis WordToMD. All major SSGs render GFM tables. See Markdown Tablas: una guía completa.
Bloques de código
Para la documentación técnica, utilice bloques de código cercados con identificadores de lenguaje para resaltar la sintaxis:
```python
def convert_document(filepath):
with open(filepath, 'rb') as f:
return mammoth.convert_to_markdown(f).value
See [Markdown Code Blocks Guide](/blog/markdown-code-blocks-guide) for all supported languages.
## Validating Markdown Before Build
Before running your SSG build, validate your converted Markdown:
- **markdownlint** — Checks for style consistency and errors
- **Vale** — Prose linting for technical writing
- **Your SSG's dev server** — The fastest way; run `hugo serve`, `jekyll serve`, or `astro dev` and check the rendered output
## Batch Conversion for Large Content Migrations
If you're migrating an existing Word-based content library to an SSG:
1. Use [WordToMD](/#converter) for individual files
2. For dozens of files, see [Batch Convert Word to Markdown](/blog/batch-convert-word-to-markdown) for command-line tools
3. Write a script to add frontmatter and rename files to your SSG's convention
A Python or Node.js script can automate the frontmatter injection after batch conversion.
## SSG-Specific Tips
### Jekyll
- Filename must include the date: `2026-05-25-your-slug.md`
- Use `categories:` for site navigation
- Liquid template tags conflict with certain curly-brace content in Markdown — escape with `{% raw %}...{% endraw %}`
### Hugo
- Hugo has strict frontmatter validation — required fields depend on your theme
- Use `hugo new content/posts/slug.md` to create a properly templated file, then paste converted content
### Astro
- Uses Content Collections with schema validation
- Ensure frontmatter fields match the schema in `src/content/config.ts`
- Astro's MDX support allows components inside Markdown if needed
### Eleventy
- Most flexible SSG — any .md file in any directory is content
- Frontmatter format is configurable (YAML, TOML, JSON)
## FAQ
**Do I need to convert each Word file manually?**
For a few files, manual conversion with [WordToMD](/#converter) is fastest. For a whole content library, [batch conversion](/blog/batch-convert-word-to-markdown) makes more sense.
**My SSG build fails after importing converted Markdown. What's wrong?**
Check for: (1) missing required frontmatter fields, (2) unescaped special characters in frontmatter values, (3) smart quotes in frontmatter strings (replace with straight quotes).
**Can Word documents become MDX files for React-based SSGs?**
Yes. Convert to standard Markdown first, rename to .mdx, then add React component imports at the top if needed. See the basics in [What Is Markdown](/blog/what-is-markdown-guide).
**Which SSG is best for a team that writes in Word?**
If your team is non-technical and writes in Word, a headless CMS (like Contentful or Sanity) with Markdown support may be a better fit than a file-based SSG. The Word → Markdown workflow works well for developers and hybrid teams.
## Conclusion
Static site generators are an excellent home for content that starts in Word. [WordToMD](/#converter) handles the conversion step; your SSG handles the publishing step. Add frontmatter, organize your files per the SSG's conventions, and you have a content pipeline that scales.