Word to Static Site Generator: Convert Docs for Jekyll, Hugo, and Astro

Static site generators (SSGs) like Jekyll, Hugo, Astro, and Eleventy consume Markdown files to build websites. If your content team writes in Word, converting that content to Markdown is the critical first step. This guide covers the complete Word to static site workflow.

The Core Workflow

Word (.docx) → Markdown (.md) → SSG build → HTML website

Each arrow is a transformation:

1. WordToMD converts .docx → .md
2. Your SSG build system reads .md and generates HTML
3. A CDN or hosting platform serves the HTML

Adding Frontmatter

Static site generators require YAML frontmatter at the top of each Markdown file. After converting with WordToMD, add a frontmatter block before the content:

Jekyll / Eleventy

---
layout: post
title: "Your Document Title"
date: 2026-05-25
categories: [tutorial, documentation]
tags: [word, markdown]
permalink: /blog/your-document/
---

Hugo

---
title: "Your Document Title"
date: 2026-05-25
draft: false
tags: ["tutorial", "documentation"]
slug: "your-document"
---

Astro

---
title: "Your Document Title"
date: 2026-05-25
description: "A brief description for SEO."
tags: ["tutorial", "documentation"]
draft: false
---

File Organization

SSGs expect content files in specific directories:

Match the filename convention for your SSG. Jekyll is the strictest: 2026-05-25-word-to-static-site.md.

Headings and Content Structure

SSGs display # Heading 1 as the page’s main heading. Since the title frontmatter field already defines the page title, use H2 (##) as your top-level content heading and avoid H1 in the body.

Before conversion, check that your Word document uses Heading 1 only for the document title, and Heading 2 for major sections. See Markdown Headings Guide for details.

Images in Static Sites

Images from Word documents need to be:

1. Exported from Word (Save As → Web Page copies images to a folder)
2. Placed in your SSG’s static assets directory (e.g., public/images/ for Astro/Next.js, assets/images/ for Jekyll)
3. Referenced in Markdown:

![Diagram description](/images/diagram.png)

Tables

Word tables convert to GFM syntax via WordToMD. All major SSGs render GFM tables. See Markdown Tables: A Complete Guide.

Code Blocks

For technical documentation, use fenced code blocks with language identifiers for syntax highlighting:

```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.