The temptation
Query cluster around "AVIF vs WebP vs HEIC 2026" is competitive and valuable. My blog id 1 covers it, published months ago, indexed, gets a small trickle of clicks. The obvious move on paper: write a fresh landing page for the head keyword, link internally, watch it rank.
I did not do that.
Why extend instead
Cannibalization. When two pages on the same domain target the same intent, Google splits the ranking signal. Both underperform. A new page also needs its own authority pool, its own indexing wait, its own crawl budget. On a 5-month-old domain still in sandbox, that trade never pays.
The alternative: take the existing post from 8 to 12 sections, 8 to 12 FAQ items, add schema_faq, refresh updated_at, add 12 internal deep-links (10 to spoke pages, 2 cross-links to my benchmark post as data source). Same authority pool concentrated on one page. Fresh timestamp signal. New internal links flowing back to spokes.
Rich Results Test came back clean: 3 valid items, 0 errors.
The safe SQL pattern
Every extension goes through the same transactional shape:
`sql
BEGIN;
UPDATE blogs
SET sections = sections || jsonb_build_object(...),
faq = faq || jsonb_build_array(...),
schema_faq = ...,
read_time = 11,
updated_at = NOW()
WHERE id = 1;
SELECT id, jsonb_array_length(sections), jsonb_array_length(faq), updated_at
FROM blogs WHERE id = 1;
COMMIT;
`
Append-only via ||, zero DELETE statements, verify SELECT before COMMIT. If the row looks wrong I ROLLBACK. In 20 weeks of running this pattern I have not lost a section.
Also this week: closing the "30 MB PNG bug"
Different topic, same theme. Every week for two months I logged "30 MB PNG output on backend" in the carried-bugs list. This week I sat down to fix it and realized there is no bug.
A 24.5 megapixel iPhone Pro photo at full resolution is 4284 by 5712 pixels. Uncompressed RGBA that is 98 MB. PNG deflate on photo content with AI-generated mask edges compresses to about 25 to 35 percent. Output: 25 to 40 MB. That is the honest number. Anything smaller means downscaling the user's photo or silently switching to a lossy format.
I shipped a WebP output toggle two weeks ago for users who want smaller files. That is the correct answer to "I want a smaller file." Silently downscaling PNG is the wrong answer.
Closed the item in my strategy file as [CLOSED: not a bug]. Two months of guilt about a non-issue.
Sandbox exit signals
GSC 3-month rolling: avg pos 52. Last two days baseline: 787 impressions, pos 42. Impressions up 77 percent week over week.
Google positions look worse on paper (52 vs 42) because impressions grew fastest on long-tail queries where I sit deeper. That is expected. The signal I care about is impressions trending up on the same content, meaning Google is testing me on more queries.
Bing meanwhile: 942 impressions, CTR 1.49 percent. Bing has forgiven the young domain. Google is still auditing. The split between the two channels is normal for a 5-month-old site, not a bug in either.
Takeaway
Two decisions this week that looked like avoidance:
- Not writing the new blog post
- Not "fixing" the 30 MB output
Both were the right call. The scoreboard is starting to agree.
Next week: YouTube demo #1 (HEIC to JPG on iPhone), second Qwoted pitch using the benchmark AI-citation data as unique hook.
Top comments (0)