Alamat email yang muncul di field author JSON-LD itu milik akun WordPress saya sendiri. Yang menemukannya adalah SEO lead di pihak klien, lewat email yang menunjukkan salah satu halaman layanan dengan node author berisi alamat tersebut di field name.
Aturan dari SEO lead itu, saya terjemahkan dengan nama pemilik brand disamarkan: "Untuk pemilik brand, kami memakai user lain hanya di sebagian halaman blog. Selebihnya, pemilik brand harus jadi satu-satunya nama di semua schema." Jadi persoalannya lebih besar dari alamat email yang terbuka. Halaman layanan bukan halaman blog, sehingga menurut aturan itu nama saya pun tidak boleh ada di schema-nya, berbentuk email atau tidak.
Di situs itu akun saya tercatat sebagai penulis setidaknya 24 entri, yaitu 15 item custom post type ditambah 9 halaman biasa. Yang bocor hanya kelima belas item custom post type. Kesembilan halaman biasa bersih.
Yang menentukan adalah tipe schema, bukan kolom penulis
Di situs ini Rank Math mengeluarkan schema Article untuk custom post type, dan Article membawa author. Untuk page biasa yang keluar adalah WebPage, dan node WebPage itu sama sekali tidak membawa author. Itu sebabnya hanya item custom post type yang membocorkan nama.
// Disederhanakan. Alamat email disamarkan.
// item custom post type: node Article, membawa author
"@type": "Article",
"author": { "name": "<alamat email akun saya>" }
// page biasa: node WebPage, tanpa author
"@type": "WebPage"Contoh paling jelas ada di bagian framework. Post type framework sengaja diset has_archive => false supaya hub-nya bisa berupa halaman yang didesain, bukan daftar arsip generik, sehingga hub itu adalah Page sungguhan. Hub itu bersih walaupun penulisnya akun saya. Lima item framework di bawah URL hub tersebut, juga atas nama akun saya, adalah custom post type, dan kelimanya ikut membawa alamat email itu. Bagi pengunjung, semuanya satu bagian situs. Bagi Rank Math, itu dua tipe schema yang berbeda.
Pemetaan seperti ini jangan diasumsikan berlaku di situs lain. Rank Math memilih tipe schema bawaan per post type lewat setelan Schema Type di Titles & Meta, dan satu post juga bisa membawa schema sendiri, jadi di instalasi lain page bisa saja mendapat Article. Untuk situs ini, catatan 18 Agustus menyebut Rank Math PRO 3.0.76 yang terpasang. Pemeriksaan wp-admin 6 Agustus mencatat modul Schema dalam keadaan aktif, dan audit di hari yang sama atas semua filter rank_math/* di tema tidak menemukan satu pun yang menyentuh schema, termasuk rank_math/json_ld. Pemeriksaan live hari itu juga mencatat Organization dan WebSite di beranda, Article dan BreadcrumbList di halaman buku, serta BlogPosting dan FAQPage di sebuah artikel. Halaman buku itu termasuk item custom post type yang dibahas di sini.
Logika yang sama menjelaskan kenapa 46 halaman yang penulisnya akun lain lagi juga tidak melanggar aturan klien. Kalau aturan itu dibaca sebagai "kolom penulis harus pemilik brand", 9 ditambah 46, jadi 55 halaman, akan terlihat seperti pelanggaran, padahal tidak satu pun mengeluarkan nama penulis di schema-nya. Karena itu penulis page tidak saya pindahkan sama sekali. Yang diperiksa adalah tipe schema yang benar-benar dikeluarkan tiap URL.
Lima belas item, padahal menu cuma menjangkau lima
Kelima belas item custom post type itu seluruhnya atas nama akun saya, tanpa kepemilikan campuran: 4 buku, 5 framework, 3 produk, dan 3 layanan. Dari menu header yang disebut SEO lead itu, hanya 5 yang terjangkau, yaitu 3 layanan ditambah 2 item lain yang dicapai lewat redirect 301 dari dua URL lain. Sepuluh sisanya saya temukan lewat query dan ikut saya perbaiki, karena keluhan yang sama akan muncul lagi di halaman buku atau framework.
Akun tujuannya juga perlu dipilih dengan teliti. Ada dua akun pengguna yang sama-sama bernama pemilik brand: akun utama dengan 516 item dan arsip penulisnya sendiri, serta satu duplikat dengan 18 item dan nicename yang jelek. Yang dipakai adalah akun utama.
Memindahkan penulis tanpa menaikkan post_modified
Penulisnya saya pindahkan dengan UPDATE post_author lewat SQL langsung, bukan wp post update, dan itu disengaja: supaya post_modified tidak naik, sehingga dateModified di schema dan lastmod di sitemap tetap jujur. wp post update berjalan lewat wp_update_post(), yang ujungnya memanggil wp_insert_post(), dan fungsi itu mengisi post_modified dengan waktu saat itu setiap kali post diperbarui. Mengganti penulis tidak mengubah isi item mana pun, jadi tidak ada alasan kelima belas item itu tampak baru diubah.
-- Disederhanakan: prefix tabel, nama post type, dan ID akun diganti placeholder.
UPDATE wp_posts
SET post_author = @owner_id
WHERE post_author = @my_id
AND post_type IN ('cpt_book', 'cpt_framework', 'cpt_product', 'cpt_service');
-- Revert: pernyataan yang sama, kedua ID ditukar.
UPDATE wp_posts
SET post_author = @my_id
WHERE post_author = @owner_id
AND post_type IN ('cpt_book', 'cpt_framework', 'cpt_product', 'cpt_service');Revert-nya memang sesederhana itu: pernyataan yang sama dengan kedua ID ditukar, dibatasi ke empat post type tadi. Ada satu syarat yang membuatnya sah. Sebelum perubahan, tidak boleh ada item di empat post type itu yang sudah milik akun tujuan, karena item seperti itu akan ikut terseret ke akun saya saat revert dijalankan. Di kasus ini syarat itu terpenuhi, karena kepemilikannya memang tidak campuran: kelima belas item seluruhnya milik akun saya.
UPDATE langsung juga melewati semua hook penyimpanan WordPress, jadi tidak ada pembersihan cache yang terpicu otomatis. Sesudahnya saya jalankan wp cache flush, ditambah rocket_clean_files() yang hanya menyasar 15 URL itu. Purge Cloudflare tidak diperlukan, karena edge kembali bersih dengan sendirinya.
Verifikasi di origin
Kelima belas URL saya periksa di origin dengan user agent peramban. Semuanya membalas 200, string alamat email itu muncul nol kali, dan node author sekarang menunjuk akun utama pemilik brand.
// Sesudah perbaikan. Disederhanakan, identifier disamarkan.
"author": { "@id": ".../author/<akun-pemilik>/", "name": "<nama pemilik brand>" }Node itu juga membawa foto asli pemilik brand dan worksFor yang menunjuk ke #organization. Di catatan saya, keluhan itu ditandai selesai pada 2 September. Yang saya pegang adalah verifikasi dari sisi saya sendiri; tanggapan pihak klien sesudah perbaikan tidak tercatat di sana.
display_name yang berisi alamat email
Terpisah dari keluhan itu, ada satu hal yang membuat kebocorannya terlihat jauh lebih buruk dari seharusnya: display_name akun saya persis berupa alamat email tadi. Rank Math mengisi name di node author dengan display_name penulisnya, jadi yang tampil di schema adalah alamat email utuh, bukan sekadar nama yang salah tempat.
Sekarang display_name itu berisi nama asli saya, supaya apa pun yang nanti tercatat atas nama akun itu tidak lagi memunculkan alamat email tersebut sebagai nama. Yang belum berubah adalah user_nicename. Nilainya masih berbentuk email, sehingga URL arsip penulisnya juga tetap berbentuk email. Arsip itu noindex dan sekarang tidak memuat satu post pun.
Catatan saya tidak menyebut bagaimana display_name itu sampai berisi email. Yang perlu diketahui secara umum: kalau akun dibuat tanpa nama depan dan nama belakang, WordPress mengisi display_name dengan user_login, dan user_nicename juga diturunkan dari user_login. Akun yang login-nya berupa alamat email bisa berakhir dengan keduanya berbentuk email.
Sebelum memindahkan penulis di situs lain
Aturan klien tadi bicara soal nama di schema, bukan soal kolom penulis di wp-admin, jadi pemeriksaan pertamanya ada di keluaran URL: tipe schema apa yang keluar, dan apakah tipe itu membawa author. Dari situ kelihatan kelas item mana yang bermasalah, dan perbaikannya bisa menutup seluruh kelas itu, bukan hanya URL yang kebetulan disebut di keluhan. Kalau ada akun duplikat dengan nama yang sama, pastikan akun tujuannya yang benar. Kalau penulis perlu dipindah tanpa membuat item tampak baru diubah, pakai jalur yang tidak menyentuh post_modified, dan tulis revert-nya sebelum pernyataan pertama dijalankan.
Terakhir, periksa display_name dan user_nicename setiap akun yang mungkin tercatat sebagai penulis. Yang pertama dipakai Rank Math sebagai nama di node author. Yang kedua membentuk URL arsip penulis, dan URL itu dipakai sebagai @id node author selama arsip penulis tidak dimatikan.