DEV Community: Dimitry Toronto Moscow

og:image not showing on LinkedIn? The 6 causes I check, in order

Dimitry Toronto Moscow — Fri, 16 Oct 2026 15:18:25 +0000

A missing or wrong link preview on LinkedIn, Slack, X or Facebook almost always comes down to one of six things. In the order I check them:

The image is SVG. None of LinkedIn, X or Facebook render SVG og:image. Use PNG or JPG.
The URL is relative. og:image="/card.png" fails; crawlers need an absolute https:// URL.
The bot is blocked. Cloudflare Bot Fight Mode / WAF rules often return 403 to facebookexternalhit or LinkedInBot. Check with curl -sI -A "LinkedInBot/1.0" https://your.site/page and look in your CDN's security events.
The image redirects or 404s. The page can be fine while the image host blocks bots or redirects to a login.
Size and type. LinkedIn's large card wants ≥1200×627; declare og:image:width/height so the first share renders.
Cache. Platforms cache the first scrape. Re-scrape in LinkedIn Post Inspector / Facebook Sharing Debugger after fixing.

Also: tags added by client-side JavaScript are invisible to most social bots, and og: tags should use property=, not name=.

Free lint for 1, 2, 5 and the markup mistakes

I put the markup checks into a single page that runs in your browser (nothing is uploaded): paste your <head>, get PASS/WARN/FAIL lines.
→ https://dimonch-byte.github.io/og-lint/

It can't see 3, 4 or 6, because those depend on what the crawler actually got back.

Disclosure

I build SharePack. Its free check requests your page the way social bots do and shows what came back. If something's broken, the optional $29 one-time pack has corrected tags and a correctly sized image set for your page. It's not a design tool: https://sharepack.adjudi.com/?utm_source=devto&utm_medium=article&utm_campaign=sharepack-intent-w2&utm_content=og-6-causes

I checked 835 top homepages: a third ship no og:image, half no apple-touch-icon

Dimitry Toronto Moscow — Mon, 12 Oct 2026 15:37:31 +0000

On 2026-10-10 I requested the homepage of the first 1,500 domains in the Tranco list (one GET each, nothing else probed) and parsed the 835 that returned HTML. No per-site results kept or named.

36% had no og:image; only 20.5% declared og:image width/height
43% had no apple-touch-icon; 69% no web app manifest
67% sent HSTS, 52% nosniff, 29% Referrer-Policy, 15% Permissions-Policy, 47% an enforced CSP (7% Report-Only)

Big-site homepages are not typical small sites; read these as a floor.

Fixes for each, with copy-paste config: https://dimonch-byte.github.io/web-fix-notes/

Free checkers (MIT, stdlib Python): og-lint-action, favicon-audit, headers-baseline on github.com/dimonch-byte.

Disclosure: I build paid fix packs for some of these (SharePack for share cards). The data and checkers are free and work without them.

CSP Report-Only is a safer first step than guessing an enforcement policy

Dimitry Toronto Moscow — Fri, 02 Oct 2026 05:09:30 +0000

I wanted a less dramatic way to start reviewing security headers on small sites.

The usual advice jumps from “your headers need work” to a copied CSP that breaks analytics, fonts, embeds, or a login flow. That is not a great deployment plan. Content Security Policy is tied to the application’s real dependencies, so a policy that looks tidy in a snippet can still be wrong for the site running it.

So I built HeaderKit: a $29 one-time pack oriented around CSP Report-Only and common security headers. You review and apply the recommendations yourself. Nothing auto-enforces a CSP on your site.

What Report-Only changes

A Report-Only policy lets a browser report violations without using the policy to block the resource. That makes it useful for discovering what the application actually loads before deciding whether enforcement is appropriate.

A small example is in this gist:

View the HeaderKit example

It includes a Content-Security-Policy-Report-Only example plus headers such as:

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy
X-Frame-Options

The CSP example includes a placeholder report collector. That placeholder is intentional: reporting only helps if you choose a collector you control and understand what it receives. Do not paste a sample policy into production unchanged and assume it matches your framework or third-party services.

A practical review loop

Inventory the scripts, styles, images, fonts, frames, and network calls your site really uses.
Start with Report-Only and watch the violations during normal flows, including login and checkout if applicable.
Remove dependencies you do not need, or decide explicitly which origins are trusted.
Tighten the policy in stages, with a rollback path.
Only consider enforcement after testing the application—not because a scanner produced a nice grade.

Nonces, hashes, inline styles, third-party analytics, payment widgets, and embedded video all change the answer. There is no universal “copy these headers” block that can account for every stack.

What HeaderKit is not

Not a WAF. It does not inspect or filter arbitrary traffic.
Not automatic CSP enforcement. You choose what to deploy and when.
Not a compliance certification. A header pack cannot certify an application or organization.
Not a promise of an A or A+ scanner score. Results depend on your stack and the configuration you actually ship.

The goal is a reviewable starting point, not a lockdown claim. If you want to see the sample before deciding whether the workflow fits, the gist is public.

I wanted deny rules for common leak paths — not a zip of someone’s secrets

Dimitry Toronto Moscow — Fri, 02 Oct 2026 05:09:17 +0000

I kept seeing the same uncomfortable class of deployment mistake: a production host that still answers for .git, .env-shaped paths, source maps, or an old backup archive.

The useful question is usually not “can I retrieve something interesting?” It is “are these paths reachable on a site I control, and what can I put in front of them before the next deploy?”

So I built LeakDeny: paste a URL you control → run a proof-style check → pay once → download a deny pack for common exposure paths. The pack is $29 one-time.

What the pack is for

LeakDeny is deliberately narrow. It gives you host-level snippets and verification steps for patterns such as:

.git and similar repository paths
.env-shaped paths
JavaScript source maps (.map)
backup archives and database dumps
a few common backup-file patterns

Before any of that, check your own site for free. This status-only script requests ~18 well-known debris paths, peeks at the first 64 bytes in memory to separate real files from soft-404s, and never prints or saves response bodies:

curl -fsSLO https://raw.githubusercontent.com/dimonch-byte/leakdeny-check/main/check-exposed-paths.sh
bash check-exposed-paths.sh https://your-site.example

Repo + free one-server nginx/.htaccess starter snippets: https://github.com/dimonch-byte/leakdeny-check

The intended workflow is boring, which is good: review the generated rules, apply them in the layer you actually operate, reload or redeploy, and verify that the paths return a denial response rather than 200 OK.

For example, the check after deployment should be something like:

curl -sI https://your-domain.example/.git/HEAD
curl -sI https://your-domain.example/.env

The exact status and routing depend on your host, proxy, CDN, and configuration. A 404 or 403 can be the desired result, but it is not proof that a file was never exposed in the past.

What it does not do

It is not a WAF.
It is not a bug-bounty scanner for strangers’ domains.
It does not remove a secret that was already committed or downloaded.
It does not rotate credentials for you.
It does not claim that a few deny rules equal a complete security review.

If a credential may have been exposed, rotate or revoke it separately. Blocking /.env today does not make an old leaked token safe. Likewise, a deny rule is only useful if it is actually applied at the right layer and tested after a CDN or framework change.

I also made a conscious decision about the proof asset: LeakDeny never packages secret contents. The example gist contains path rules only. I would rather publish a small, reviewable configuration fragment than turn a security check into a mechanism for collecting or redistributing someone’s data.

Try it

Use it on a URL you own or are authorized to test. The paid pack supports Apache/.htaccess and nginx directly, with manual snippets for Vercel and Netlify. On other hosts (Caddy, Cloudflare rules, managed platforms) the free starter snippets show the intent, but LeakDeny will tell you it's unsupported before you pay.

Your site has no clean brief for AI agents — so I shipped a $19 four-file pack

Dimitry Toronto Moscow — Fri, 02 Oct 2026 04:47:41 +0000

I kept needing a short, honest brief for AI tools crawling a small site — not another SEO dashboard, and not a promise that ChatGPT will cite me.

So I built CiteKit: paste a public URL → free check → preview four files → $19 one-time zip via Paddle.

What you get

Spec-shaped /llms.txt (editorial map, not a sitemap dump)
Organization + FAQPage schema.jsonld
FAQ drafts (faq.md)
Stack README

What it is not

Not rankings
Not “get cited by ChatGPT/Perplexity”
Not citation monitoring
/llms.txt is a community convention, not a guarantee

Who it’s for

Indie / small marketing sites (Next.js, Framer, Webflow, Carrd, Ghost, static hosts) that don’t already emit this via Yoast / Mintlify / GitBook.

Try it

Site: citekit.adjudi.com
Example /llms.txt shape: https://gist.github.com/dimonch-byte/1c0e50c793c85239b3f03e7392bd5f7d

Operator: 9213651 Canada Inc. · Support: idealstoronto@gmail.com · MoR: Paddle