LinkedIn publishing strategy

Why We Stopped Putting Links in LinkedIn Posts (And You Should Too)

We tried to auto-post links to LinkedIn comments. LinkedIn's API said no. Turns out that's fine – reach beats clicks anyway.
A marketer reviews a social media post draft while deciding whether to optimize for reach or clicks.

The clever workaround was not the real decision.

We built a WordPress plugin that could publish posts to LinkedIn automatically. The tempting next step was to remove the link from the post and add it as the first comment, hoping to keep reach while still giving people a path back to the article.

LinkedIn made that harder than it looked. More importantly, the restriction forced a better question: are we publishing for reach, or are we publishing for clicks?

The operating question

If the post needs reach, why put a link in the post at all?
If the post needs clicks, is LinkedIn the right channel for that job?
If the workaround needs two apps and two token flows, is the automation still worth it?

There are really three LinkedIn choices.

The first-comment trick sounds like a small implementation detail, but it changes the product decision. Each choice optimizes for a different outcome.

Link in the post

This is the direct traffic choice. It gives people an immediate click path, but the post may reach fewer people because the platform has less reason to keep it moving in the feed.

Link in the first comment

This is the workaround choice. It can be useful manually, but automating it means dealing with separate API permissions and a more fragile user setup.

No link in the post

This is the reach choice. The post stands on its own with image and copy, and the link can still be added manually when the situation calls for it.

The API restriction clarified the strategy.

The Comments API required Community Management API access, and that product could not sit beside the posting products we needed in the same LinkedIn app.

A two-app setup was possible in theory, but it would make the plugin harder to configure, harder to support, and easier to misunderstand.

What the restriction changed

The basic WordPress-to-LinkedIn publishing flow still worked.
The automated first-comment link moved into a separate permission problem.
Users would need to understand and authorize more than one LinkedIn app.
The extra complexity served a tactic, not the core publishing job.
The better product was the simpler one: publish strong image-led posts and let manual comments handle exceptions.

Choose reach or clicks before you build the workflow.

A LinkedIn post should have a job. The job decides whether the link belongs in the post, in a comment, or nowhere at all.

Use reach when

the goal is visibility, authority, brand recall, or keeping the post alive in the feed.

Use reach when

the post can deliver value without requiring a click.

Use reach when

the image and copy can make someone remember the company even if they never leave LinkedIn.

Use clicks when

the landing page is the main value and the audience needs the full resource immediately.

Use clicks when

you are willing to trade some visibility for a direct path to the site.

For most everyday business posts, reach is the stronger default. Add the link manually when the post has a clear click job.

The plugin did not fail. The feature got smaller.

The useful part of the automation stayed intact: publish from WordPress with the image and post copy. The part we removed was the brittle tactic around comment automation.

What stayed in the product

  • WordPress posts can still become LinkedIn posts automatically.
  • Featured images still do the visual work in the LinkedIn feed.
  • The publishing flow stays understandable for normal site owners.

What we chose not to automate

  • A separate Comments API setup for the first-comment link trick.
  • Two LinkedIn app products and token paths for one small tactic.
  • A feature that would look clever but make the user experience worse.

Measure the post by the job it was given.

The question is not whether every LinkedIn post sends traffic. The question is whether the post did the job you chose for it.

For reach posts, look at impressions, profile visits, reactions, saves, comments, and later branded search.
For click posts, look at click-through rate, landing-page engagement, and conversion quality.
For manual first-comment links, check whether the extra step actually changes outcomes enough to keep doing it.
Compare posts with and without links over time instead of trusting one anecdote.
Keep the publishing workflow simple unless the data proves the complexity earns its place.
The practical source of truth is your own LinkedIn and analytics data, not a universal rule about links.

A simple workflow that consistently gets published usually beats a clever workflow that people stop using.

Frequently asked questions

Should every LinkedIn post avoid links?

No. If the click is the point of the post, include the link. If the post is mainly for visibility and authority, the post may work better without a link.

Is the first-comment link tactic still useful?

It can be useful as a manual habit. The problem is not the tactic itself, but turning a small manual step into a complicated automation flow.

Why not build the two-app LinkedIn setup anyway?

Because it adds configuration, support, and token complexity for a feature that may not improve the main outcome. The cleaner product is easier to use and easier to trust.

Stop fighting the feed by default.

LinkedIn is usually better at creating visibility than sending immediate traffic. Treat that as the default, then make deliberate exceptions.

1

Write the post so it delivers value without a click.

2

Use a strong image that makes the post worth stopping for.

3

Add a link manually when the post truly needs one.

4

Only automate extra complexity after the data says it is worth it.

The point is not to avoid links forever. The point is to know what job the post is doing before the link decides the design.