Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstalliTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Moving 500 posts from WordPress to Nuxt is a manageable content job. The hard part is everything around the text: keeping every valuable URL working, carrying titles, descriptions and canonical tags across, and making sure the HTML your new site delivers matches what the old one served. Work through the project in this order: back up everything, inventory every public URL, extract the content, map old addresses to new ones, choose how Nuxt renders each route, then reconcile, test, launch and monitor.
Start with a backup you have actually restored
WordPress’s official migration guidance says to back up the WordPress directory, images, plugins and other files as well as the database before you move anything. A backup only counts once you have proven it can be read, so treat the first backup as a test you have to pass.
- Copy the full file tree over SFTP or SSH, including
wp-content(themes, plugins anduploads) and any customised core files. Keep a copy off the server. - Export the database through your host’s control panel, phpMyAdmin, or from the command line, for example
mysqldump -u DB_USER -p DB_NAME > site-backup.sql. - Open the SQL dump and confirm that the
wp_poststable (or your table prefix equivalent) contains rows. Then restore the dump into a separate staging database and load the site. A successful download does not prove that every record is present.
What WordPress’s export covers, and what it leaves out
The built-in export lives at Tools > Export in the WordPress admin. It produces a WordPress eXtended RSS (WXR) XML file that carries posts, pages, comments, categories, tags, authors, custom fields and attachment references. That covers the editorial core of a 500-post blog. It does not cover everything you will need for the rebuild.
- Widget configuration is not included. Sidebar and footer content must be recorded by hand.
- Plugin and blog settings are not included in the documented method. SEO plugin settings, form configuration, redirect rules and menu structures need separate records.
- Plugins can cause empty or partial exports. Compare the number of items in the XML with the counts shown in the admin. The Posts screen lists counts for All, Published, Drafts, Scheduled and Trash, and the export should match the statuses you intend to migrate.
Keep the XML file as a snapshot of the content. It is not a complete backup of the site.
Build an inventory before you build anything
Turn the backup into an inventory spreadsheet. Each row is one public URL or one content record, and the columns should capture what the new site needs to know:
- Source URL, post ID, post type and status (published, draft, private, scheduled)
- Intended destination URL on the Nuxt site, and whether it is unchanged, re-slugged, merged or removed
- Categories, tags, author and custom fields in use
- Shortcodes, embeds, galleries and any block or page-builder markup
- Images and files referenced in the body and their paths, plus alt text
- Internal links pointing at other posts, pages and media
- Title tag, meta description, canonical URL and any structured data
- Traffic and ranking value, so that high-value pages get the most care
The 500-post figure is the size of this particular project. It is not a benchmark, and the effort it implies depends far more on how many shortcodes, custom fields and special templates the site uses.
Extract the content: export file or REST API
There are two practical ways to pull content out of WordPress. Most small and medium sites should start with the XML export, then use the REST API to fill gaps the export cannot reach.
| Method | What it gives you | What to check before relying on it | Best fit |
|---|---|---|---|
| Tools > Export (WXR XML) | Posts, pages, comments, categories, tags, authors, custom fields | Widget and plugin settings are not included; plugins can produce partial output; compare counts per status | One-time extraction of editorial content into a parser or import script |
| WordPress REST API | Posts, pages, taxonomies and other built-in resources as JSON | Private and password-protected content, users and custom post types need authentication or explicit exposure; metadata availability varies by site | Programmatic extraction with pagination and record-level checks |
| Direct database export | Every row, including settings and meta tables | Requires parsing serialised PHP data and careful handling of shortcodes and media paths | Forensic completeness checks and recovering content the other routes miss |
Using the REST API without losing records
The core posts endpoint lives at /wp-json/wp/v2/posts, and pages use /wp-json/wp/v2/pages. Request 100 records per page, the maximum the core endpoints accept, and read the X-WP-TotalPages and X-WP-Total response headers so you know when you have every page. For 500 posts, that is five requests.
curl -sI "https://your-site.example/wp-json/wp/v2/posts?per_page=100&page=1"
curl -s "https://your-site.example/wp-json/wp/v2/posts?per_page=100&page=1&_fields=id,slug,link,status,title,date_gmt,modified_gmt"Compare the total from the headers with your admin counts. Anything that differs points to a permissions issue, a status filter, or a post type you have not requested yet.
Two limits matter here. Custom post types appear under the REST API only when they are registered with REST support, and private or drafted content needs an authenticated request. Revisions and custom fields are reachable only if the site exposes them. Inspect the real responses on your own site before designing an importer, and do not assume the endpoint returns the whole content model.
Map every old URL before you write a single redirect
A rebuild is a URL migration. Search engines, bookmarks and links from other sites point at addresses, not at content, so the URL map is the most important deliverable in the project.
- Collect URLs from several sources and merge them: WordPress’s core sitemap (
/wp-sitemap.xmlon WordPress 5.5 and later, unless an SEO plugin replaces it), a full crawl of the live site, your analytics landing-page report, and server access logs for paths that receive traffic but are missing from the sitemap. - Classify each URL as unchanged, changed (new slug or new structure), merged into another page, or intentionally removed.
- Write one destination for every changed URL. Avoid redirect chains, where A points to B and B points to C.
- Decide on trailing slashes, uppercase paths, query strings and attachment or media URLs, and handle each category explicitly.
Nuxt 4 route rules can declare redirects directly in nuxt.config. Always set the status code yourself. Use 301 for a permanent move, and do not copy the example from the documentation, which uses a 302 redirect.
Rank #3
export default defineNuxtConfig({
routeRules: {
'/2019/05/old-post-slug/': {
redirect: { to: '/guides/new-post-slug', statusCode: 301 },
},
},
})For 500 posts, a large part of the map may be a pattern such as a date-based path or a category prefix. Write those as pattern rules where your Nuxt setup supports them, and keep an explicit list for the exceptions.
Choose the rendering mode route by route
Nuxt uses Nitro for server rendering and prerendering. The choice affects what the crawler receives on the first request, which is why it belongs in the migration plan rather than in a later performance tweak.
| Mode | What the first response contains | SEO implication stated in Nuxt’s deployment guidance | Typical fit for article routes |
|---|---|---|---|
| Prerendered (static HTML generated at build time) | Complete HTML for each prerendered route | Preserves the crawl and metadata benefits of rendered HTML | Strong fit for articles that change rarely |
| Server-side rendered (rendered per request) | Complete HTML generated by the server on request | Also delivers rendered HTML to users and crawlers | Useful for pages with live data or frequent updates |
| Client-only (rendered in the browser) | A minimal shell that JavaScript fills in | Loses many of the SEO benefits of prerendering | Avoid for article content |
Choose the mode per route, not per project. Most blog-style articles can be prerendered, while search pages, comment forms or a live listing may need server rendering. Whatever you choose, confirm the result in the delivered HTML. A quick check looks like this:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
curl -s https://staging.your-site.example/guides/new-post-slug/ | grep -E "<title>|meta name="description"|rel="canonical""If the title, description and canonical tag appear only after a browser runs JavaScript, the page is not delivering what a crawler needs.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Carry metadata across, not just body text
Copying the post body is the easy part. Each of these items needs a deliberate decision and a check on the rendered output:
- Titles and meta descriptions for every route, including posts that used the SEO plugin’s defaults and were never edited by hand.
- Canonical URLs, so duplicate paths such as parameters or preview URLs point back to the preferred address.
- Open Graph and social tags, if the old site generated them.
- Structured data, if the old site emitted it, and whether the new markup is valid for the page type.
- Robots directives, including any
noindexpages that must stay out of the index. - Archive and pagination routes for categories, tags, authors and dates. Decide which archives survive, which become redirects, and which are removed with a 404 or 410 response.
- Images: keep paths or redirect them, preserve alt text, and check that the sizes and formats are still served correctly.
- Internal links, rewritten to the new URLs in the body, not left to pass through redirects.
- Sitemap, robots.txt and RSS feed generated for the new domain structure.
- 404 behaviour, so that missing pages return a real 404 status rather than a soft error page.
Shortcodes, galleries and embeds need their own rules. Each one is either converted to a component, rewritten as plain HTML, or documented as removed. Broken media references should be listed in the inventory rather than discovered after launch.
Reconcile and test on staging before launch
- Count by type and status. The number of published posts, pages and drafts on the new side should match the source inventory, with any intentional exclusions listed.
- Check IDs and slugs. Find missing records, duplicated slugs and titles that changed during import.
- Check media links. Request every image and file path referenced in the migrated content and confirm a 200 response.
- Crawl the old URL list against staging. Classify each result as an expected 200, an expected redirect to a single destination, or an intentional removal. Anything else is a defect.
- Test representative templates. Include posts with embeds, galleries, unusual custom fields and broken media, not only the clean examples.
- Inspect delivered HTML for titles, descriptions, canonical tags and body content, as shown in the rendering section.
Launch and watch the first weeks
- Freeze content on the old site for the cutover window, then run one final export and compare it with the previous one to catch late edits.
- Switch DNS or deployment and confirm that the homepage, a sample of article URLs, a redirected URL and a removed URL all return the expected status.
- Watch 404 logs for paths missing from the map, and fix them with a redirect to the most relevant destination.
- Check for redirect chains and loops, and reduce any chain to a single hop.
- Track indexing and crawl reports in Google Search Console and compare organic landing-page traffic with your pre-move baseline. Keep the baseline export so the comparison is like for like.
Traffic and SEO: what the move can and cannot promise
Two worries appear most often in discussions of this kind of project: whether the site will lose organic traffic, and whether moving to Nuxt itself improves search performance. The first is largely within your control. Traffic is protected by a complete URL map, single-hop redirects, preserved metadata and rendered HTML that matches the old pages. The second is not something a framework can guarantee. Nuxt can deliver prerendered or server-rendered HTML, which is a sound foundation, but any ranking or speed gain depends on what the new templates actually do. No independent published figure for WordPress-to-Nuxt migrations of about 500 posts was found, so treat any traffic projection as a hypothesis to measure, not a forecast.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesAnswer these questions about your own site before estimating effort
The effort for this project depends on facts that are not visible from the project brief. Collect them from the site owner before setting a timeline or promising results:
- The current URL structure, including date-based, category-prefixed or custom paths
- Post types beyond posts and pages, and whether they are exposed to the REST API
- Plugins that generate content, shortcodes in use, and custom fields that feed templates
- Media dependencies, broken files and the size of the uploads folder
- Forms, comments, search, integrations and any member or private content
- Which pages and sections carry the most traffic and must be verified first
- The editorial workflow after launch, including who publishes and how often
- The target hosting and deployment model for the Nuxt build
With those answers, the inventory, URL map and rendering decisions become specific, and the plan can be sized realistically.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
