English, for you

"Your trial ends tomorrow, 26 August. Before it does I owe you an honest assessment. ClearPost sent nine posts. You published three and six sit in drafts. I looked at why you did not publish them and I think you were right. Four of the six are nearly the same topic as an article you already have. You already have 'Kasko Değer Listesi Nedir?' and 'Tamamlayıcı Sağlık Sigortası ile SGK Arasındaki Farklar'. That is our fault. When we built the plan we read only 10 of the 360 posts on your site. The 30 posts in the queue carry the same risk. The other two drafts are different: you have nothing on 'Plakadan Sigorta Sorgulama' or 'TSS mi ÖSS mi?'. I would publish those two. The three you published carry 2026 figures. The DASK post also sends five internal links into your older home insurance articles. That is the part that strengthens your existing content. One more thing: your AXA contracted-hospitals page sits between position 14 and 19 for four keywords, which is 13,510 searches a month. That does not need a new article, it needs a better title on that page. What should we change? I can rebuild the plan against all 360 of your posts."

The duplication, post by post

I pulled all 360 public posts from their REST API and matched each unpublished draft against them.

2309 is the clearest case. Our title and theirs open with the identical five words. And their version was in the sample we showed the model, so the model saw it and planned a duplicate anyway.

The product defect, read in the code today

keywordResearchService.ts:117 calls getExistingPostTitles(siteId, 20). :1274-1287 reads the 20 most recent rows of our own posts mirror, not their live site. :1313 then passes slice(0, 10) to the LLM.

Two failures stack:

• Our mirror holds 49 rows. Their site has 360. We know about 13.6% of their content.
• Those 10 titles feed seed-keyword extraction only. Nothing anywhere compares a planned calendar title against their existing library. Deduplication is not a weak step here. It does not exist.

This is not specific to this customer. Any site with an existing content library gets a calendar that partly re-writes what they already published. I have not opened a task for it. Say the word and I will, with this account as the evidence.

Attribution: all three published posts are unmatchable in GSC

This is the ?p= defect from the churn analysis, live on a trial today, and it is worse than that write-up said. Three published posts, three different failure modes:

The churn analysis only counted the third mode. The backfill in COMMITMENTS.md fixes ?p= URLs. It will not fix an empty one and it will not fix a stale slug. The fix has to re-read the live permalink by wp_post_id, not rewrite the stored string. I have not changed the backfill plan. Flagging it because it changes the job.

Rankings, Turkey, not the US

scripts/trial-email-data.py:92 hardcodes location_code: 2840 and language_code: "en". Run as-is it reports 2 keywords, best position 38. Run against location 2792, language tr it reports 193 keywords. Same trap as roshni.com.pk yesterday. Third time. I will fix the script to take a location argument.

The honest shape of their site: 193 ranked keywords, but only 3 on page one and 8 on page two. The big volumes sit at position 50 to 76.

The one bright spot is a single page. /axa-tamamlayici-saglik-sigortasi-anlasmali-hastaneler/ holds four keywords at positions 14 to 19, worth 13,510 searches a month: axa anlaşmalı hastaneler (6,600, pos 18), axa sigorta anlaşmalı hastaneler (5,400, pos 19), axa tamamlayıcı sağlık sigortası anlaşmalı hastaneler (1,300, pos 14), axa sigorta hangi hastanelerde geçerli (210, pos 19). That is the email's one gift.

Trial record

The zero-deletions number matters. Trashing is our highest-fidelity quality signal, and they trashed nothing. They read six articles, judged them redundant, and left them alone. This is not a customer who thinks the writing is bad.

Checks

• 196 words in Turkish. No em dashes. No manual line breaks.
• Goes to knnygr@gmail.com, the address on the trial row.
• No price and no upgrade link. Yesterday's email carried both. Repeating them the next day is the desperate version.
• Every post claim verified against their live REST API this morning, not against our status column.
• No predicted numbers, and no claim that our three posts have earned traffic. I cannot claim it: all three URLs are unmatchable in GSC.
• "I can rebuild the plan against all 360 posts" is a promise in your name. It is real work and I can do it. It is the correct offer, because the duplication is ours. I added it to COMMITMENTS.md section B.
• I did not quote the live post titles, because our generator rewrites titles on delivery and a changed title is not a customer edit.

My recommendation

Send it. Yesterday we asked them to buy. Today we tell them we got their content plan wrong, name the four duplicates, and offer to fix it. That is the only honest reason to appear in their inbox twice, and it is a better conversion argument than the one we sent yesterday, because it proves we looked at their site.

If they reply, do not sell. Rebuild the calendar against all 360 posts first. The 30 queued rows have the same duplication in them, so converting them today would ship the same problem for money.