Jekyll、Hugo、Astro 和 Eleventy 等靜態站點生成器 (SSG) 使用 Markdown 檔案來構建網站。如果您的內容團隊使用 Word 編寫內容,則將該內容轉換為 Markdown 是關鍵的第一步。本指南涵蓋了完整的 Word到靜態站點 工作流程。
核心工作流程
Word (.docx) → Markdown (.md) → SSG build → HTML website
每個箭頭都是一個變換:
- WordToMD 轉換 .docx → .md
- 您的 SSG 構建系統讀取 .md 並生成 HTML
- CDN 或託管平臺提供 HTML 服務
新增 Frontmatter
靜態站點生成器需要 YAML 前言 。轉換後 WordToMD,在內容之前新增一個 frontmatter 塊:
傑基爾/十一
---
layout: post
title: "Your Document Title"
date: 2026-05-25
categories: [tutorial, documentation]
tags: [word, markdown]
permalink: /blog/your-document/
---
雨果
---
title: "Your Document Title"
date: 2026-05-25
draft: false
tags: ["tutorial", "documentation"]
slug: "your-document"
---
阿斯特羅 每個 Markdown 檔案頂部的
---
title: "Your Document Title"
date: 2026-05-25
description: "A brief description for SEO."
tags: ["tutorial", "documentation"]
draft: false
---
檔案組織
SSG 期望特定目錄中的內容檔案:
| SSG | 部落格文章目錄 |
|---|---|
| 傑基爾 | _posts/ (檔名: YYYY-MM-DD-slug.md) |
| 雨果 | content/posts/ |
| 阿斯特羅 每個 Markdown 檔案頂部的 | src/content/blog/ |
| 十一 | 您配置的任何目錄 |
| Next.js | content/ or posts/ (取決於設定) |
匹配您的 SSG 的檔名約定。Jekyll是最嚴格的: 2026-05-25-word-to-static-site.md.
標題和內容結構
SSG 顯示 # Heading 1 作為頁面的主標題。自從 title frontmatter 欄位已經定義了頁面標題,使用 H2 (##) 作為您的頂級內容標題,並避免在正文中使用 H1。
轉換之前,請檢查您的 Word 文件是否僅使用標題 1 作為文件標題,並使用標題 2 作為主要部分。看 Markdown 標題指南 。
靜態站點中的影像
Word 文件中的影像需要:
- 從 Word 匯出(另存為→網頁將影像複製到資料夾)
- 放置在您的 SSG 的靜態資產目錄中(例如,
public/images/對於 Astro/Next.js,assets/images/) - Markdown 中引用:

表格
字表通過以下方式轉換為 GFM 語法 WordToMD. All major SSGs render GFM tables. See Markdown 表:完整指南.
程式碼塊
對於技術文件,請使用帶有語言識別符號的隔離程式碼塊進行語法突出顯示:
```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.