WordPress Link Shortener: Short Links Made Every Time You Publish

A WordPress link shortener turns a post's long permalink into a short link you can share. The good setup creates that link the moment you hit Publish, so nobody has to copy the URL into a shortener after the fact, forget to tag it, or skip it on a busy day.

This page is for teams that publish on WordPress and then share each post across email, social and paid channels. We think the short link should appear on its own at publish time, on your own branded domain, with tracking already attached. By the end you'll know where the redirects should actually live, how to wire the publish hook, why one post usually needs several channel variants, which domain to put on your branded short links, and what you should expect to get back in the reports.

Should Your Short Links Live Inside WordPress?

No. There's a whole category of redirect plugins that store short links as rows in your WordPress database, and they look convenient right up until you need them to work.

Think about what happens when someone taps one. The request hits your web server, WordPress boots, PHP loads the plugin, the plugin looks up the slug in the database, and only then does the reader get sent onward. Every short link click is a full request against your site. That's fine on a quiet Tuesday. It's less fine when a post gets picked up somewhere big and the same server is trying to render the article and answer a flood of redirect lookups at the same time.

Then there's everything that takes the site offline. A host outage, a migration to a new server, a bad plugin update, someone deactivating the redirect plugin while debugging something unrelated. Any one of those breaks every short link you've ever shared, including the ones sitting in old emails and on printed material you can't take back.

The click counts aren't much better. When you paste a link into a chat app, the app fetches it to build a preview. Search crawlers follow it too. Most redirect plugins log all of that as clicks, with no way to tell a reader from a fetcher.

A proper redirect hop does more than forward people. In the moment between the tap and the destination loading, it records when the click happened, the referrer, the country and the device, and scores the request for how likely it is to be a bot. Our guide on how short link redirects work walks through that moment step by step. Doing it reliably under load is a job for infrastructure that only does redirects, separate from the CMS that's also busy serving your blog.

If you run a small personal blog and you'll never open a click report, a plugin is fine. Nobody gets hurt. Everyone else should let WordPress create the link and let something built for the job answer it.

Hook the Shortener Into the Publish Button

WordPress already tells you the exact moment a post goes live. The transition_post_status action fires on every status change and passes you the new status, the old status and the post object. When the new status is publish and the old one isn't, the post has just gone out. That's when you create the link.

The code is short. In the callback, skip any post type you don't care about, then check post meta for a short link you've already saved. If one is there, stop. If not, send POST /api/v1/links with the permalink as url, plus tags or a campaignId if you want them. Then write the short URL and the link's id from the response into post meta. Use a meta key with a leading underscore so it stays out of the custom fields box, and register it so the editor and your templates can read it. The id matters more than it looks, because it appears on every click event later. Our URL shortener API guide covers the request and response in full.

A few details catch people out.

• First publish only. Check that the old status wasn't publish. Without that check, every typo fix creates a new link.
• Idempotency. The meta check is your guard. A retry after a timeout should find the saved link and do nothing, so write to meta as soon as the response arrives, before anything else has a chance to fail. One gap remains. If a timeout hits after the link was created but before the answer reached you, the post has no saved link and a retry makes a second one. If you set a custom alias, that retry is refused as already in use, which tells you the first call worked.
• Scheduled posts. A scheduled post moves from future to publish when WP-Cron runs, so the same hook catches it. A visitor's page load often triggers that cron run, so keep the request timeout short and don't let a slow response hold up the page.
• The API key. Put it in wp-config.php as a constant. Anything stored in the options table ends up in database exports, staging copies and backups, and more people can open those than you'd expect.

Keep that key narrow. Acturity API keys carry permissions, so give this one write permission without delete, and a compromised site can't delete your links. You can also give the key a daily and a monthly quota, so a buggy loop can't create thousands of links overnight.

One Post, Many Short Links

A single short link per post works until you share it in three places. Say the post goes out in Tuesday's newsletter, then on LinkedIn, then gets a small paid boost. If all three point at the same short link, you get one click total and no idea which share earned it.

So have the publish hook create a few variants instead of one. Keep the set small and fixed (newsletter, LinkedIn and paid is plenty for most teams) and give each one a destination with UTM parameters already attached. The newsletter version carries utm_source=newsletter and utm_medium=email, the LinkedIn version carries its own pair, and so on. You end up with links like go.example.com/redirect-guide-nl and go.example.com/redirect-guide-li. Each is its own short link with its own click count.

The values come from code, not from whoever happens to be sharing that day. Nobody types utm_source by hand, so nobody writes "Newsletter" one week and "news-letter" the next. Write the vocabulary down once, lowercase with dashes, and put it in the hook. Our guide to UTM naming conventions that hold up has a scheme you can copy.

Then group the variants, but not in one campaign. An Acturity campaign adds its own source and medium to every link in it, and those replace the ones in your destinations, so all your variants would report as one channel. Give the variants a shared tag, such as the post's slug, so you can find them together. If you want campaigns, make one per channel (one for newsletter links, one for LinkedIn) and pass that campaign's ID for the matching variant. That way, when someone asks which channel drove the reads on last month's launch post, the links are easy to find together and nobody has to rebuild the answer from a spreadsheet. If you're setting campaigns up from scratch, we cover it in building a campaign tracking system.

When Readers Hover Over the Link

Nobody reads the long part of a short link. They read the domain. The reader hovering over it in your newsletter, the spam filter scanning the email, the chat app deciding whether to unfurl a preview all judge the link by what sits before the first slash.

A default shortener domain next to your company name looks like something a stranger pasted in. Phishing uses those same domains, and filters treat them accordingly. A short branded domain like go.example.com/launch-notes reads as yours. It also outlives the tool, because the domain belongs to you. If you ever switch platforms, you can recreate the same addresses in the new tool, because the domain is yours.

Set it up once. In Acturity that's a pointing record so links resolve (a CNAME for a subdomain) and a TXT record to verify you own the domain. SSL follows automatically after verification. From then on, every link the publish hook creates comes out on your domain without anyone choosing it. We go deeper on the setup in branded link domains.

A WordPress Link Shortener Earns Its Keep in the Reports

Making a long URL shorter is the trivial part. Any tool does it in a few milliseconds, and nobody has ever been promoted for it. The value is in the answer to the question someone asks every Monday: which posts got read, and where did those readers come from?

A good weekly view for one post is small. You want the post's channel variants next to each other, so the newsletter link and the LinkedIn link sit together with their click counts. You want clicks by day across the week, so you can see whether the post died the afternoon it went out or kept picking up readers. You want clicks broken down by referrer, country and device. And you want suspected bots on their own line, because a link preview fetcher in a chat app isn't a reader, and you should know how much of your number is machines before you quote it in a meeting. Acturity's bot traffic report shows that split. Its headline totals still include suspected bots by default.

Then there's the problem nobody plans for. Someone deletes or unpublishes an old post, and every short link shared for it now lands on an error page. If you switched health monitoring on for that link, the next check sees the error and alerts your account's owners and admins, so you don't have to wait for a reader to tell you.

Acturity's API and click analytics by country and device cover the clicks, the referrers and the bot report, if you want to try it on your own posts. Once the publish hook is in place, the links make themselves and the numbers collect themselves. Nobody on your team has to think about short links again.