Word to Blog · Your App Cloud
Turn Word documents into blog posts
Upload a few articles, one Word file each, or a long archive with an article under each heading. Check every post's date, byline and summary, then give readers categories and a next read.
From a folder of articles to posts in date order.
Say what counts as one post, name the line each field comes from, then read the blog the way a first-time visitor would.
01
Say what counts as one post
Attach the Word files with the upload button above. Say whether each file is one post, or whether a long document holds many, one under each Heading 2. Start with a handful that differ: the oldest, the newest, one full of photos and one by a guest writer.
02
Name the line behind each field
Tell the prompt where each post's title, date, byline and category sit, for example 'the date is the line under the title'. Where an article has no summary, write one sentence for it, or have the building assistant in Studio draft it and correct the draft against the post.
03
Read it as a first-time visitor
Open the index on a narrow screen and confirm it runs newest first. Open the oldest post, follow its category and click the next read at the bottom. If you keep drafts in the app, paste a draft's address into a private window and confirm it doesn't open.
Where each part of an article goes.
Every row starts with something dated writing in Word tends to carry. The quoted lines are invented, taken from an imagined monthly newsletter of a bike shop in Santa Cruz, California.
| In your Word files | On the blog | What to check |
|---|---|---|
| One file per article, with a name such as 'Rain ride prep FINAL v2' | A post with its own address, such as /rain-ride-prep | If a title or address came from the file name, look for 'final', 'v2' or 'copy' in it. Once a post's link has been shared, keep that address even if you retitle the post, so the old link still opens it. |
| A yearly compilation, with each issue as a Heading 1 and each article as a Heading 2 | Separate posts, each dated with the issue it came from | Count the articles in the compilation and the posts on the index. A short item without a Heading 2 of its own, such as 'Holiday hours', reads as part of the article above it. |
| The byline under the title: 'By Priya Nair' | The author shown on the post, and a list of each writer's posts | Word keeps its own Author property, under Related People in File, Info. It comes from the user name of whoever created the file, so it may name the shop owner on every post. Check each post shows the name from its byline. |
| A date line such as 'March 2024 issue' or 'Posted June 3, 2025' | The publish date that sorts the index | The date a file was last saved tells you when someone last edited it, not when readers first saw it. Where only a month is given, pick a day and use it for every post from that issue. |
| The 'In this issue' box, with a one-line teaser per article | The summary under each title on the index | Match every teaser to its own post. Rewrite a teaser that says 'inside' or 'on page 3', because a blog reader arrives at one post at a time. |
| Recurring section names, such as Ride Reports and Workshop Tips, or a 'Tags:' line at the end | Categories readers can browse | Read the list of categories. 'Workshop Tips' and 'Workshop tips' should be one category, and a category holding a single post may belong inside another. |
| Words written for the mailing date: 'this Saturday's group ride', 'sign up by Friday' | Text that still reads right after that date has passed | Search each post for 'this week', 'tomorrow' and 'next'. Put the date in, or cut the line if the ride or the sale is over. |
| Photos labeled with Insert Caption, such as 'Figure 7: The Highway 1 climb' | Images in the post, each with a caption and alt text | Word numbers captions across the whole file, so Figure 7 in a compilation may be a post's first picture. Change 'see Figure 7' to 'the map below'. Check each photo sits in the post it belongs to, not the one before it, and has alt text of its own. |
| Footnotes, and endnotes gathered at the back | Numbered notes at the end of the post, or links on the words they support | Word places endnotes at the end of the document by default, so in a compilation one article's notes can sit many pages away. Check each note number leads to the right note inside its own post. |
| An unfinished article, with 'DRAFT' in its file name or header | Left out of a one-page site. In an app with data, a draft you limit to writers who sign in | A one-page site has no sign-in, so keep drafts out of what it publishes. In an app with data, open a draft's address while signed out, where it should not load, and again signed in as a writer. |
Written for subscribers, read by anyone.
Articles kept in Word were often written for a mailing list, a staff newsletter or print. A blog is public and read one post at a time, sometimes years later. Go through a copy of the files with that reader in mind.
The copy that actually went out
A newsletter folder often holds two or three versions of one article, and the newest file isn't always the one readers got. Pick one file per article. Where you're unsure, compare it with the sent email or the printed issue.
Permission that covered a mailing list
A photo a customer sent in for the newsletter, or a rider named in a ride report, was shared with subscribers. The open web is a much wider audience. Ask again, or take the photo or the name out.
Prices, hours and offers that expired
An old article may quote a tune-up price or store hours that have changed since. Decide post by post: update it, add a line such as 'Prices as of spring 2024', or leave the post out.
Suggestions still waiting in the file
A post that went back and forth with an editor can still hold suggested edits and margin notes. Accept or reject them in Word before you upload, so the post you publish is the version you signed off on.
An illustrative starting point
A blog built from your archive.
One post per article with its date, author and summary, an index in date order, categories to browse and a next read after every post.
An index in date order
Each post appears with its title, date, author and summary, newest first. Check that the top of the index shows your latest article, not the file you happened to upload last.
Categories and authors to browse
A reader who liked one Workshop Tips post can open the others, or everything Priya Nair wrote. Keep the category list short enough to read on a phone without scrolling sideways.
A next read under every post
End each post with a link to one or two related posts, from the same category or ones you choose. Click through a few and check that none of them leads back to the post you started on.
Room for next month's article
On a one-page site, a new post means editing the blog in Studio and publishing again. In an app with data, posts can live in a database that writers update in the app, and a task on a schedule you set can make a finished post public on its date. Try that with a test post and check the index that day.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Database
Keep data and context for apps and agents
File storage
A home for your documents and media
Authentication
Give the right people access
Security
Secure every connection
A little more context
Good questions.
Should each article be its own Word file?
Separate files keep each post's date and byline next to its text, and suit a handful of articles. A whole archive is easier as one long compilation, if every article starts at the same heading level, usually Heading 2, with its issue date in the heading above. Say which layout you have in the prompt, then count the posts in the preview.
Where do the post dates and authors come from?
From lines in the text that you name, such as the date under the title and the 'By' line. Word's saved date and its Author property describe the file, not the article. Spot-check a few posts where the byline and the file's author differ.
Can I publish the blog on the Free plan?
Yes, as a one-page site that only presents your posts, so each new post means an edit in Studio and a fresh publish. A page for each post, writers who sign in to add posts, drafts kept inside the app or posts released on a schedule make it an app, which needs a paid plan to go live.
How do I keep drafts from being seen?
On a one-page site, leave them out of what you publish, because it has no sign-in to hide them behind. In an app with data, drafts can stay in the app with the access you describe for each collection. Open a draft's address in a private window before you trust that it stays hidden.
What happens to footnotes and figure numbers?
Check them post by post. With one file per post, say whether footnotes should become numbered notes at the end, or links where a note is only a web address. In a compilation, figure numbers and endnotes run across the whole document, so reword 'see Figure 7' and move each article's notes with it.
Can our writers add posts without emailing me a Word file?
Yes: give the published blog a writers' sign-in, with the access you describe for each collection, so they add and edit posts there. Studio itself has one builder per Exepad account. Readers stay separate and read the public posts without an account.
Can I move my posts somewhere else later?
You can export your app's data and code. Keep your original Word files too, since they hold each article as it was written. Before you count on an export, run one and check that the posts, dates and images you care about are in it.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Give your writing a personal website ↗
See the outcome and the capabilities behind it.
Plan drafts and published posts ↗
The docs page on content apps: the fields a post needs, and how to test a draft, an edited post and an address that doesn't exist.
Understand data and context ↗
Give information the right place in your app.
Prepare to publish ↗
Check the experience you will share.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building