Social share cards across every site
I checked all 22 live sites by fetching the real pages and reading the tags that actually shipped, then re-fetched every share image to confirm it returns a real picture rather than a 404 or an error page dressed up as a success. Here is what was broken and what is fixed. Audited 2026-07-26.
Fixed
These sites were sharing as bare links with no picture. Each one now has the full tag set and a share card built from the site's own words and colors. Click any domain to open it.
Was: Hub pages had no social tags at all. The homepage pointed at an image filename that never existed.
Now: Full tag set on every hub page, plus a new card. Homepage image path corrected.
Was: Tags were correct but pointed at og-default.png, which was never created, so it returned a 404.
Now: Card created and shipped.
Was: Missing card image, twitter:image and og:url on every page.
Now: Card created, plus og:url and the Twitter image tag.
Was: No image and no Twitter tags at all, across all 35 pages.
Now: Card plus the full Twitter set on all 35 pages.
Was: No image, no Twitter title, description or image on any page but the homepage.
Now: Fixed in the page generator, so a future rebuild cannot wipe it again.
Was: No social tags of any kind, on any page.
Now: Full tag set on all 41 pages, plus a card.
Was: Every page pointed at og-image.jpg, which was missing, so all 117 pages shared with no picture.
Now: Card created. Spanish, French and Portuguese pages now declare their own language.
Was: Only the homepage had a card. Every research and article page shared with no picture.
Now: Card created and set as the fallback for every page.
Was: Had an image, but was missing og:url, og:type and the Twitter title and description.
Now: Remaining tags added.
Was: 65 pages wrote the image as a relative path, which no social crawler can resolve, so they shared with no picture. This passed a first look because the tags were all present.
Now: The layout now resolves the image against the site address. All 65 verified fixed. Two image problems remain, in the note below.
Was: Card was missing, and the domain had never been connected, so nothing resolved.
Now: Card created, domain connected, SSL live on both tasteboulder.com and www. Cards verified working.
Already correct
These passed every check with no changes needed.
| Site | Result |
|---|---|
| ajijic.org | No change needed. |
| smartstrongalive.com | No change needed. |
| sponsorlab.ai | No change needed. |
| househelperhub.com | No change needed. |
| newtoboulder.com | No change needed. |
| outdoorboulder.com | No change needed. |
| boulderthingstodo.com | No change needed. |
| trainerbooked.com | No change needed. |
Waiting on you
| Site | Situation |
|---|---|
| menopausepracticegrowth.com | Left alone on purpose: the site is password-protected, so nothing can share it. Say the word and I will add them. |
Bone Voyage photos: what I found
I checked the share photo on all 1,067 Bone Voyage pages, one image at a time. Three groups came out of it:
| 112 pages | Photo is 1200 by 630 or bigger, which is what the platforms ask for. Genuinely crisp. Nothing to do. |
| 577 pages | Big enough to render as a full-width card, but under the recommended size, so it looks soft on a modern screen. 250 of these are 600 by 400. |
| 276 pages | Under 600 by 315, which is the floor. These show as a little thumbnail beside the link instead of a picture. |
| 102 pages | The photo is gone from storage. The address still answers as if it worked, but it hands back the Bone Voyage homepage instead of a picture, which is exactly why a routine check passes it. |
Put together: 853 of the 1,067 pages, about 4 in 5, are below the size the platforms recommend, and 378 of those are genuinely not working as cards at all. An earlier version of this page said only 276 were undersized. That number counted just the ones below the bare floor and let the soft middle group pass, which flattered the result.
You asked me to look for larger versions of the small photos. My first answer was that they did not exist, and that was wrong. I had checked Cloudflare storage, the local backup of the old site's uploads, and the other photos on each page, and come up empty. What I had not checked was the old hosting box itself.
It is still running, and it still has the original photos. The domain points at Cloudflare now, so nothing reaches that server by name any more, but it answers on its own address and hands over the files. Checking all 378 broken or undersized photos against it:
| 112 photos | A properly sized original is sitting there. Real photographs, no enlarging needed. One of them is 200 by 300 on the site and 3817 by 5726 on the old server. |
| 166 photos | The original is small too, so enlarging is the only route. |
| 100 photos | Not on the old server either. Genuinely gone. |
I have not yet run the same check on the 577 soft ones, and that is probably the bigger prize, since they were skipped only because they were not broken. If the same proportion holds, a good share of those have a full-size original waiting too.
Where no original survives, enlarging works. I ran a 300 by 200 shot of dogs at a pet resort through the enlarger you already have on this machine and it came out at 1200 by 800 in about ten seconds, still clearly the same dogs and perfectly readable at card size. A 600 by 400 photo came out at 1600 by 1067 in about twenty seconds. It costs nothing and runs locally.
But a real original always beats an enlarged one, so the order matters. What I would do:
- Pull the 112 real originals off the old server and repoint those pages.
- Run the same check across the 577 soft ones and pull whatever comes back bigger.
- Enlarge the 166 whose originals are small too.
- Put the brand card on the 100 with nothing left to recover.
Steps one and two come first because every real original found is one fewer softened photo. Say go and I will run it. The full write-up, including what is recoverable and how, is on its own page: Bone Voyage photo recovery (password protected, same password as the health hub).
One thing worth acting on regardless: that old server is the only remaining copy of these originals. The local backup holds just the small crops the migration happened to need. If the hosting ever lapses, the full-size photos are gone for good, so a complete copy of the uploads folder belongs in cold storage.