Migrate a WordPress blog to HubSpot: what actually moves?

A blog with hundreds of posts is the cheapest and hardest-to-rebuild asset a marketing operation has. It was produced over years, earned authority, and a good share of the company's organic traffic today comes in through a handful of those old articles.

So when the decision to migrate a WordPress blog to HubSpot comes up, the question that stalls the room is never "can it be done". It is "what do I lose along the way".

The answer is more predictable than it looks, because HubSpot documents field by field what the import carries. The problem is that almost every piece of material on the subject treats it as if there were a single button, when there are four routes with different requirements.

It is worth drawing the boundary right away: migrating the site is a different project, with its own service scope and a full structural redirect plan, covered in the step-by-step guide to migrating WordPress to HubSpot. Here the subject is the editorial archive, field by field.

What are the ways to migrate a blog from WordPress to HubSpot?

HubSpot documents four official content import methods for blogs: a direct WordPress connection, an XML file, smart copy and a CSV file.

Caption: to migrate a WordPress blog to HubSpot is to decide, field by field, what the import carries and what stays behind

They all arrive at the same place, a blog inside Content Hub (formerly CMS Hub), but they start from different points of access to the source content.

Most teams know one of them and assume it is the only one.

The difference between them is not quality, it is prerequisites. One depends on a technical interface being open on your server, another on your being able to generate an export file, another reads the content the way a visitor would.

Knowing there are three alternatives turns a blocker into a detour. Here is how each one sits:

Table: Methods and scope according to HubSpot's content import documentation.

The decision sequence is short: if the source is WordPress, try the direct connection; if it cannot read the blog, go to XML; if the source is neither WordPress nor Squarespace, smart copy; if the archive is small or you need field-by-field control, CSV.

How does HubSpot's WordPress connect work?

WordPress connect is the method HubSpot describes as the fastest and most automated when the site supports the standard REST API of WordPress.

You provide the URL of the blog's home page, the platform reads the archive, lists the posts it found and you select what to import. It is available across all products and plans.

That last detail heads off a common budget question: importing a blog is not a higher-tier feature. What does exist is a permissions requirement, because the user needs edit, publish and import permissions.

The path is direct: in settings, under Content > Blog, open the current view menu, choose import blog, then blog posts, then WordPress connect. Provide the home URL, choose which HubSpot blog receives the content, have it copy the posts, review the list and select the ones that come across.

Two points appear at the end and deserve attention before the click. The first is the choice between importing as a draft or already published.

The second point is the option to overwrite existing content, useful on a second run and dangerous if someone has already edited the posts inside HubSpot after the first load.

A note of technical honesty: there is no official published number for the maximum quantity of posts in this method, and any limit quoted elsewhere is a third-party estimate.

The safe route is to run a small pilot import, check the result and only then process the whole archive.

When should you use XML, smart copy or CSV import?

The three alternative methods cover the cases where the direct connection does not apply. XML import handles sources in WordPress or Squarespace and uses the export file from the platform itself. Smart copy reads blogs from any CMS. CSV starts from a spreadsheet you build, with the post fields filled in.

The order of preference is not arbitrary.

Importing a blog by XML is the natural alternative when the REST API is unavailable, because the WordPress or Squarespace export file is generated at the source and does not depend on HubSpot reaching your server through a programmatic interface. If IT will not open the API, that is the detour.

Smart copy solves the most open scenario: any CMS, including proprietary platforms and tools with no decent export. It works from the published content, which makes it the only viable option when administrative access to the source has already been lost, a frequent situation with blogs inherited from previous agencies.

CSV is the control method, where you build the spreadsheet, decide the value of each field and upload it. It makes sense for small archives or when the operation prefers to standardize SEO titles and meta descriptions before publishing, rather than fixing them afterwards.

One scope detail that avoids frustration: knowledge base articles have their own import, separate from the blog. If your operation keeps both in WordPress, those are two projects.

What migrates from each WordPress post to HubSpot?

The direct WordPress connection brings nine elements of each post: title, SEO title, meta description, body, author information, publish date, featured image, categories and tags.

It is an explicit inventory in the documentation, which lets you plan the post-import check precisely instead of auditing everything in the dark.

What may be a pleasant surprise is the presence of the SEO fields. SEO title and meta description come along, which means optimization done over years does not have to be redone article by article. What stays behind is short, but specific:

Table: Scope of what is and is not imported according to HubSpot's WordPress blog import documentation.

The practical reading is that the content itself travels well. What demands attention is the periphery: author profiles, structures that are not ordinary posts, and checking how each featured image behaves in the new template.

What does not migrate and needs manual work afterwards?

Two items are documented as out of scope, custom post types and the author profile image, which HubSpot records will not be imported unless it is included in the body of the post. There are few items, but both can represent real volumes of work depending on how the WordPress site was built.

Custom post types deserve a pause.

In WordPress, it is common for case studies, testimonials, job openings, courses, events and downloadable materials to have been created as their own structures, rather than as blog posts.

From the manager's point of view, all of that "is on the blog". From the import's point of view, it is not a blog, and it does not come. Drawing up that list before anything else usually redesigns the schedule.

Author profiles are small, visible work: since only the author information travels, the photos have to be re-uploaded and associated inside the platform.

There is a third front as well, which project practice teaches you to check: internal links pointing to the old URLs and image references still served by the source domain. Those links work on import day and become a problem when the old structure goes offline.

Prioritizing the twenty articles that sustain the traffic resolves most of the risk for a fraction of the effort. Prioritizing gets easier when the operation is already clear on how to optimize the blog.

Why does a blocked REST API stop you importing posts into HubSpot?

Because WordPress connect works by reading the blog through WordPress's standard REST API. Without that access, HubSpot cannot see the archive and the import never starts. The most common cause is not a fault, it is a security plugin doing exactly what it was installed for, and HubSpot documents the scenario itself.

This is the point that generates the most support tickets with no diagnosis.

The symptom is subtle. The screen asks for the blog's home page URL, you provide it, and the result is a generic failure or an empty list.

Nobody thinks of a plugin, because the site is live and the blog opens in the browser. And the blog is not broken: the REST API is a separate door from the one visitors use, and it is common for it to be closed by a hardening policy.

Checking is simple and does not require server access. Open the API's standard endpoint in the browser, adding /wp-json/wp/v2/posts to the blog's domain.

If a data-formatted response comes back, the interface is accessible. If an authorization error, a 403 or a block page comes back, there is the cause of the import that will not move.

From there the conversation changes hands: it stops being HubSpot support and becomes a decision for whoever administers the WordPress site, between opening access during the import window or keeping the block.

If the answer is to keep the block, the detour is already mapped, which is the XML import.

In migration projects, the mistake that costs the most time here is insisting on the automated method for days instead of taking the detour on the first failed attempt.

Should you import the posts as drafts or publish them straight away?

The import lets you bring the posts in as drafts or already published, and the choice defines the level of control.

Draft is the advisable default for any archive of meaningful volume, because it lets you check formatting, images and URLs before the content becomes visible. Publishing straight away only makes sense when the destination blog is not live yet.

The difference shows up when something goes wrong, not when it goes right. Importing published means any formatting problem, broken image or duplicate title is born visible to visitors and to search engines. Importing as a draft means the problem is born internal, and you decide when it stops being so.

There is a legitimate counterpoint in favor of publishing straight away: drafts at high volume create a review queue that needs people and a deadline, and an archive sitting still generates no traffic at all.

The arrangement that works combines the two: import everything as drafts, publish in batches by traffic priority and set a cut-off date for the remainder even without individual review.

That way the articles that sustain the operation go in first and checked, and the long tail does not stay stuck indefinitely.

What do you do with the old URLs to migrate a blog without losing rankings?

Map each old URL to the new one and create 301 redirects. This is the layer the import does not cover: the official WordPress connect article deals with copying content, not preserving positions. Migrating a blog without losing rankings depends on the redirect, and it is configured elsewhere in the platform.

It is worth insisting on this point, because it is the origin of almost every traffic loss in an archive migration.

The tool sits under Content > Domains & URLs > URL Redirects, and the documentation describes two formats: a standard redirect, from one URL to another, and a flexible pattern, which updates addresses based on the structure.

The 301 code, permanent, is the default for new redirects. There is also bulk upload by spreadsheet, the only sustainable route for hundreds of posts.

The flexible pattern is what saves work on a blog.

Blogs have repetitive structures, and it is common for the change to be only a prefix, for example from /blog/2019/03/post-title to /blog/post-title. One well-written flexible rule resolves hundreds of cases at once, while the standard redirect is reserved for the exceptions.

And there is a limitation to read before any planning: HubSpot redirects only work on domains connected to and hosted on the platform. If the old blog is still served by a domain hosted elsewhere, the redirect has to be done at the source provider.

The domain limitation ties the archive decision to the infrastructure one, because the rules for connecting a domain in HubSpot determine what is possible on each subscription, including the existence of one primary subdomain per content type. Settling that before the import avoids republishing the archive later.

Which blog settings are left over after the import?

The import brings content, not configuration. What remains afterwards are the blog's own definitions: template and listing layout, author profiles, consolidated taxonomy, URL and subdomain, analytics integration, excluding internal traffic from the metrics, reviewing the SEO recommendations and checking the forms that appear in the posts.

HubSpot's own official publishing checklist lists configuring the blog settings as an item separate from content migration. Five fronts usually stay pending and are worth treating as tasks with an owner:

• Template and listing. The migrated post takes on the destination blog's template, and details such as the featured image crop, author display and pagination only show up after the first publication.
• Consolidated taxonomy. Categories and tags come from the source, including the duplicates and the ones used only once. This is the best moment to consolidate, because the effort is already open.
• Authors. Profiles, bios and photos have to be built inside the platform, since the photo does not travel in the import.
• Analytics. Excluding internal traffic prevents the first post-migration report from being read as growth when it is the team itself browsing. The migrated archive starts feeding the reports, and reading data inside HubSpot becomes reliable to the extent that this base is clean.
• Technical SEO. Running the platform's SEO recommendations review over the freshly imported archive tends to reveal empty meta descriptions and duplicate titles that already existed at the source and went unnoticed for years.

None of these tasks is difficult. All of them are invisible, and that is why they disappear from the schedule. The work of content optimization inside HubSpot starts here, and it is what turns a technical import into a real marketing gain.

Frequently asked questions about migrating a WordPress blog to HubSpot

So how do you plan the archive migration without stalling production?

Start with the inventory, not the tool. How many posts exist, how many of them are actually blog posts rather than custom structures, which twenty bring most of the traffic and what the current URL pattern is. With those four answers in hand, choosing between the four methods takes minutes and the schedule stops being a guess.

Then settle the order: subdomain defined, pilot import, field-by-field validation, redirects mapped, full import as drafts, publication in batches by priority and only then the old archive goes offline.

That is the same dependency logic that governs the rest of the project, and it becomes clearer when implementing HubSpot is read as chained phases instead of parallel tasks.

A well-migrated archive keeps the inbound marketing machine running through the platform switch, instead of restarting from zero.

Half the decision is still missing. Anyone calculating the cost of bringing the posts across will also need to decide what to do with the pages, the forms and the structure of the institutional site.

The scope of that other half, with what the official service includes, what it leaves out and how to handle redirects at volume, is in the guide to migrating WordPress to HubSpot without losing SEO.