I have a live website whose pages load some of their content through JavaScript and API requests. The project is ending, so I'll be shutting down the backend and want to preserve the current site as a completely static version. The migration should retain the rendered text, images, CSS, fonts, and other assets. I tried wget and HTTrack, but they mostly captured the original HTML and missed content inserted after the JavaScript ran. Would Playwright, Puppeteer, or another browser-rendering workflow be the best solution, or is there a more suitable way to archive and deploy the site?
4 Answers
Another option is to preserve the API responses instead of baking everything into the HTML. Crawl the site, save each parameterless API response as a local JSON file, and change the frontend requests to load those files from the static host. This works well when the existing JavaScript UI can remain mostly unchanged, but you’ll need to account for query parameters, authentication, timestamps, and any endpoints that generate changing data.
If the pages are generated from known data, the cleanest long-term approach may be to recreate the site with a static-site generator. Export the content and assets, generate one HTML file per route, and deploy the output to a static host. That usually produces a cleaner result than archiving browser DOM snapshots, though it takes more setup if the current application has many interactive features.
The important distinction is that wget only downloads server responses; it doesn’t execute the JavaScript that builds the page. A browser automation tool can render the page first, but saving the final HTML alone may still leave broken references to external assets or API endpoints. Make the asset URLs local, choose a static-host-friendly folder and URL structure, and add fallback routing for client-side paths.
For pages that depend on JavaScript, use Playwright or Puppeteer. Have the browser visit each URL, wait for the required API calls and rendering to finish, then save the resulting DOM and download the referenced assets. A small site can be handled manually, but for dozens or hundreds of pages you’ll want a script driven by a sitemap or URL list. Also test links, client-side routes, lazy-loaded images, and any content that appears only after scrolling or interaction.
If there are only around 20–25 pages, a browser save tool such as SingleFile may be quicker than writing a crawler. For a large site, build a repeatable Playwright pipeline so you can rerun it and verify that every page and asset was captured.