Operations

How to Update an Evergreen PDF Guide Without Starting Over

By AI Creation Forge · 7 min read

The Direct Answer

Update an evergreen PDF by dating the file, changing only the pages that went stale, writing a short changelog a buyer can scan, and sending that note to people who already paid. You start over when the job of the guide has changed, not when a menu label moves. A guide can stay useful for years if the version a buyer holds matches the version you describe.

Picture Camille in her home office on the first Monday of March, opening a scheduling guide she sold in 2024. A reader emailed that the app screenshots show a button that is no longer there. The method in the chapter is still right. The picture is wrong. She does not need a new book. She needs a version, a fixed figure, and a way to tell buyers which file they should download.

Put a date where the buyer can see it

Add a version date on the first page and in the file name you upload. "Scheduling guide, March 2026" is a fact. "Ultimate edition" is not. The date tells Camille which export is current when she has three files on her desktop. It tells the buyer whether the email they received points at the new file.

Write the date from the day you actually checked the steps, not from the day you first had the idea. If you only fixed one chapter, say so in the changelog rather than implying every page was rechecked. A date without a note is still better than no date. A date with a lie next to it is worse.

When the sales page names the version, keep the page and the file on the same date. A page that says "updated for this year" and a PDF that still shows last year's screenshots is the complaint you are trying to avoid. The sales page checklist is the place to align that sentence with the file.

Change the parts that went stale

Make a list of what can rot. Tool menus, prices, platform rules, laws, and "click here" paths rot. A principle such as "write the agenda before you send the invite" usually does not. Camille lists the screenshots, the app's plan names, and one sentence about a free tier she has not reopened. She does not rewrite the chapter on how to decline a meeting.

Open the official page for each item on the list and correct the guide from that page. If the official page is confusing, say that the reader should check it, and quote only what you can point to. Do not refresh a number from memory because the old number looks round. Delete a claim you cannot recheck this week.

Screenshots are the expensive part. Replace the ones that show the wrong control. Leave a screenshot that still matches. Retaking every figure because you want a new color grade is how a small fix becomes a month. If the layout changes while you are in the file, rerun the phone pass in formatting for mobile readers and the structure pass in accessibility basics. A fresh export can break tags and type size even when the words got better.

You might be thinking you should wait and batch updates once a year. A wrong button is worth fixing when you learn about it. A yearly pass is still useful for the items that rot quietly, such as prices and plan names. Put that pass on a calendar you will open. The calendar is a habit, not a statistic about how often guides should change.

Write a changelog a buyer can scan

At the front of the file, keep a short list: the date, and what changed, in the order a buyer cares about. Camille writes: "March 2026: replaced the scheduling-app figures in chapter 4. The decline script in chapter 6 is unchanged. Removed the sentence about a free tier that the app no longer offers."

That list does three jobs. It shows buyers you looked. It stops you from forgetting what you changed. It keeps you from announcing "brand new guide" when you fixed two figures. Do not pad the changelog with adjectives. "Improved" is meaningless. "Replaced chapter 4 figures" is something a person can check.

If you use a writing tool to restyle a chapter during the update, reread the chapter against your sources before you upload. A smoother paragraph that invents a menu is not an improvement. Disclosing AI help still applies to the new version. If the help changed, the sales-page sentence should change with it.

Tell the people who already paid

Decide, before you sell the guide, how a buyer gets a new file. Then do that thing. Common honest options: a download link that always points at the current file, or an email when you replace it. Pick one and write it on the sales page. "Lifetime updates" with no delivery path is a slogan.

Camille's page says buyers can re-download from the receipt link, and that she emails when a chapter changes. She sends a short note: what changed, where it is in the file, and the link. She does not attach a guilt trip about leaving a review. The note is a delivery.

If your email includes a pitch for a second product, follow the commercial-email checklist in building an email list, including a working way to opt out. A pure "your file was replaced" note should still be accurate in the subject line. "Your guide" is fine. "You need to see this" is not, if the change is two figures.

People who bought a marketplace listing may not be on your list. Read that platform's current help page for how buyers re-download. Do not assume the email you have is the email they used to pay. Say on your own page what you can actually do.

Know when to write a new guide instead

Start a new file when the reader's job has changed, not when the screenshots have. If Camille's guide was "run a better meeting for a team of five" and she now wants to teach conference keynotes, that is a different product. Bolting it onto the old PDF makes the changelog dishonest and the outline a mess. Retire the old promise or keep selling the meeting guide as the meeting guide.

A new guide gets its own outline. Use the one-afternoon outline rather than duplicating chapters you have not reread. You can point old buyers to the new file without pretending it is included in the price they already paid. If it is included, say so in the original terms and deliver it.

Leave the old version available if someone needs the steps that matched an older tool, and label it with its date so nobody thinks it is current. Deleting the only copy you have is how you lose the ability to answer "what did I buy?"

The update is done when a buyer who opens the file today can follow the steps without hitting a control that is not there, and can see what you changed. Look at your own last page: which step would fail if you tried it this week? Fix that step, or tell the reader it needs a check you have not done. Do not upload a file you would not follow yourself.

FAQ

Do I need a new cover for every update? No. Change the cover when the title or the promise changes. A version date on the first page is the update signal.

Should I raise the price when I update? Only if the job got larger in a way you can describe. A screenshot fix is not a new product. If you do change the price, say what the new buyer gets. The pricing guide is about that decision, not about rewarding yourself for maintenance.

What if I do not know who bought the guide? Use the receipt path the platform gives you, and say on the sales page that re-download is how updates arrive. Build a list only from people who asked to be on it.

How do I handle a rule I am not sure about? Delete the specific claim and tell the reader which official page to open. An outdated rule is worse than a gap you admit.

Can I update the outline and not the PDF? Not for long. If the outline is your source of truth, the exported file has to match it before you announce a version. Buyers cannot download your outline.

What belongs in the email subject? The guide's name and the fact of an update. Save the detail for the first lines of the message, where you say which chapter changed.