Anda tidak perlu memahami fungsi canonical tag sebelum memakai Codex untuk memperbaiki sebuah halaman. Anda memerlukan satu URL halaman, akses ke proyek website saat siap melakukan perubahan, dan satu aturan sederhana: Codex memeriksa terlebih dahulu; Anda menyetujui perubahan sesudahnya.
Panduan ini menunjukkan cara aman bagi pemula untuk mengotomatiskan pekerjaan SEO berulang dengan Codex dan skill seo-auto-optimizer. Anda akan meminta Codex memeriksa halaman, menjelaskan temuannya dengan bahasa biasa, menyiapkan pembaruan yang disetujui di berkas website, lalu menguji hasilnya sebelum dipublikasikan.
Otomatisasi SEO bukan berarti menyerahkan website kepada agen dan meminta "perbaiki semuanya". Artinya, agen menangani bagian yang lambat dan berulang, sementara Anda tetap memegang keputusan yang dapat menghapus halaman dari pencarian atau membingungkan pengunjung.
Hasil yang akan Anda miliki
Pada akhir alur kerja pertama ini, Anda akan memiliki:
- satu URL penting yang diperiksa untuk masalah SEO yang terlihat;
- daftar singkat perubahan yang diprioritaskan dan dapat dibantu Codex;
- penjelasan bahasa sederhana untuk setiap rekomendasi;
- kumpulan perubahan yang sudah ditinjau dalam proyek website lokal, jika Anda memilih menerapkannya; dan
- daftar pemeriksaan sebelum deployment.
Untuk percobaan pertama, sediakan 30 sampai 60 menit. Pilih satu halaman yang penting bagi bisnis: beranda, halaman produk, halaman layanan, atau artikel blog yang sudah memiliki trafik. Jangan memulai dengan seluruh website.
Selesai berarti Anda dapat menunjuk halaman tersebut, menjelaskan apa yang berubah dan alasannya, serta memastikan halaman tetap berfungsi setelah pembaruan. Ini bukan jaminan kenaikan peringkat. Mesin pencari membutuhkan waktu untuk merayapi ulang dan menilai halaman.
Sebelum mulai: siapkan empat hal
Anda dapat memulai tanpa Google Search Console atau latar belakang teknis. Pemeriksaan pertama memakai sinyal halaman publik. Siapkan hal-hal berikut:
| Yang diperlukan | Alasannya | Jika belum memilikinya |
|---|---|---|
| URL halaman publik | Codex membutuhkan halaman tertentu untuk diperiksa. | Mulailah dari beranda atau satu halaman layanan. |
| Berkas proyek website | Codex dapat menyiapkan perubahan yang disetujui pada berkas sumber yang sebenarnya. | Minta salinan atau akses repository kepada pengelola website. Jangan mengubah berkas produksi secara buta. |
| Pratinjau lokal atau staging | Anda perlu melihat halaman sebelum dipublikasikan. | Gunakan fitur pratinjau platform atau minta tautan staging kepada developer. |
| Cara deployment | Bisa berupa Git, CMS, atau dashboard hosting. | Untuk percobaan pertama, lakukan deployment secara manual. |
Google Search Console, Bing Webmaster Tools, dan ekspor crawler berguna kemudian. Ketiganya menjawab pertanyaan yang tidak dapat dijawab oleh satu halaman, misalnya halaman yang kehilangan klik, dua URL yang bersaing, atau masalah pengindeksan dalam skala besar.
Buat skill SEO Auto Optimizer di repository Codex Anda
Anda perlu membuat berkas skill sendiri. Tidak ada lampiran yang perlu diunduh dari artikel ini.
Opsi tercepat: kirim artikel ini ke Codex
Setelah artikel ini dipublikasikan, Anda dapat memberikan URL-nya kepada Codex dan memintanya memasang skill. Salin prompt berikut, ganti [URL ARTIKEL] dengan URL artikel ini, lalu kirim ke Codex. Codex perlu membaca panduan repository yang sudah ada lebih dulu:
Baca artikel ini dan pasang skill seo-auto-optimizer persis seperti instruksinya:
[URL ARTIKEL]
Saya pemula. Baca dulu AGENTS.md dan konfigurasi .codex di repository ini hanya untuk menentukan direktori skill proyek. Kemudian temukan blok kode SKILL.md lengkap di artikel dan pasang persis di lokasi yang sudah dikonfigurasi.
Sebelum menulis berkas, beri tahu saya path lengkap yang akan digunakan. Setelah selesai, tunjukkan 10 baris pertama dan pastikan nama skill adalah seo-auto-optimizer.
Jangan periksa website saya, jangan mengubah berkas website, jangan mengganti pengaturan, jangan deploy apa pun, dan jangan menjalankan audit SEO. Hanya pasang dan verifikasi skill ini.
Jika Codex tidak dapat membuka URL artikel, gunakan cara manual di bawah. Jika perlu, Anda dapat menempelkan blok kode lengkap ke chat setelah prompt tersebut.
Di repository Anda, periksa AGENTS.md dan folder .codex jika keduanya ada. Keduanya mungkin sudah menentukan lokasi skill proyek dan pemeriksaan yang harus dilakukan. Jangan menggantinya dengan template umum.
Jika tidak ada lokasi skill proyek yang dikonfigurasi, minta Codex menyebutkan path yang akan digunakan sebelum membuat apa pun. Setelah lokasi dikonfirmasi, struktur yang diharapkan adalah:
repository-anda/
skills/
seo-auto-optimizer/
SKILL.md
Nama folder dan nilai name di berkas harus sama-sama seo-auto-optimizer. Codex kemudian dapat memanggilnya dengan $seo-auto-optimizer. Jangan membuat AGENTS.md SEO baru jika repository sudah memilikinya; artefak peninjauan Anda nanti adalah Git diff, bukan perubahan tanpa jejak.
Buka berkas teks biasa baru bernama SKILL.md dan tempel seluruh isi di bawah. Jangan menempelkannya ke kode website. Berkas ini berada di folder skills/seo-auto-optimizer/.
Skill dimulai dalam mode baca-saja. Ini disengaja: skill memeriksa bukti publik dan membuat rencana perbaikan, tetapi tidak menerbitkan halaman, mengirim sitemap, mengubah Search Console, atau mengubah situs live Anda.
---
name: seo-auto-optimizer
description: Audit one public URL or a group of website URLs with evidence, then create an SEO optimization plan ranked by impact and effort. Use when a user asks to check, diagnose, optimize, or create an SEO task list, especially for indexing, technical SEO, metadata, structured data, content quality, internal links, search intent, keyword cannibalization, Core Web Vitals, mobile experience, CTR, Google Search Console, Bing Webmaster Tools, sitemaps, robots.txt, or E-E-A-T. By default, audit and provide code or copy recommendations only. Do not change the website, CMS, search-engine consoles, or third-party platforms.
---
# SEO Auto Optimizer
Turn a supplied URL into a verifiable SEO optimization plan that a developer, content team, or growth team can act on. Never present an item as checked or fixed when public evidence cannot confirm it.
## Working boundaries
- Default to read-only work. Inspect public pages, resources, and public site files. Do not change live pages, submit a sitemap, publish content, buy links, or operate any account.
- For a single-URL request, audit that URL and only the same-domain public files needed to verify it, such as `robots.txt`, a sitemap, or page links. Do not turn a single-page observation into a site-wide conclusion.
- Mark work that needs a login, search-performance data, a full crawl, server logs, or business facts as `Needs data`. State what data is needed and how to check it.
- Do not recommend black-hat, manipulative, or fabricated SEO: no purchased links, fake reviews/authors/comments, doorway pages, keyword stuffing, or bulk low-value AI pages.
- Follow the site's market, page language, URL conventions, and content standards. Proposed titles, meta descriptions, H1s, and body copy must use the target page's language.
## Inputs and clarification
A request needs at least one URL. If available, use the target market, language, business model, primary conversion, target keywords, Google Search Console or Bing exports, and local website project.
When those details are missing, do not block the work. Infer what you can from the page language, page type, and visible content, then state your assumptions at the beginning of the report. Ask one focused question only when the user requests keyword strategy, competitive content, or a site-wide change and the answer would materially depend on the target market or business.
## Audit process
### 1. Build an evidence baseline
1. Record the inspection date, final URL, HTTP status, redirect chain, `<html lang>`, visible robots instructions, and page-rendering limits.
2. Read the first screen, main content, and available source or DOM. Record the title, meta description, canonical, robots meta, viewport, H1-H6, visible publish or update date, author information, approximate body length, images, internal and external links, JSON-LD, and important JavaScript dependencies.
3. Check the same-domain `/robots.txt`. Check a sitemap only when one is discoverable; do not say a sitemap does not exist merely because its URL is not explicitly listed.
4. Keep locatable evidence for every conclusion: tag text, HTTP header, link URL, DOM observation, screenshot observation, or public-tool result. If the page is blocked by a WAF, login, geography, or another access limit, state the limitation immediately.
### 2. Classify every check
Use exactly one status for each item:
| Status | Meaning |
| --- | --- |
| `Pass` | Public evidence shows the item meets its purpose. |
| `Issue` | Public evidence shows an error, risk, or clear omission. |
| `Opportunity` | It may not be an error, but there is a reasonable opportunity to improve visibility, click-through rate, user experience, or conversion. |
| `Needs data` | Google Search Console, Bing, logs, a full crawl, field performance data, or keyword data is required. |
| `Not applicable` | The page type or business does not need this item; explain why. |
Do not turn `Needs data` into an `Issue` just to fill a checklist. Resolve the root causes that affect crawling, indexing, user experience, or the page's main intent before minor copy changes.
### 3. Create an action plan
Merge findings into non-duplicative tasks and rank them:
- `P0`: The page cannot be crawled or indexed; an incorrect canonical; accidental `noindex`; critical 4xx/5xx; site-wide robots blocking; severe mobile or rendering failure.
- `P1`: Main-page intent or content mismatch; duplicate or thin content; missing or conflicting title and H1; unacceptable structured data; missing key internal links; obvious performance bottleneck.
- `P2`: CTR improvements; images and alt text; FAQs; author and update information; content expansion; topic or comparison pages; local link and URL improvements.
- `P3`: Growth experiments, link earning, business profiles, and monitoring that require performance data or external coordination.
For every task, state the problem, evidence, recommended action, owner (developer, content, SEO, or growth), acceptance criteria, and risk or prerequisite. Give specific code or copy only when current information supports it. Where brand facts are missing, use clear placeholders instead of inventing facts.
## What to check
### A. Crawling, indexing, and URLs
Check and report:
- HTTP status, whether redirects are single-hop and appropriate, loops, and HTTP/HTTPS or www/non-www confusion.
- `robots.txt`, meta robots, `X-Robots-Tag`, and whether canonical URLs are reachable, absolute, single, self-referencing, or point to a sensible preferred URL.
- Whether canonical, `noindex`, pagination or filtering rules, and sitemap behavior agree. Mark uncertain cases as `Needs data`.
- Whether URLs are stable, readable, descriptive, free of meaningless parameters, case or trailing-slash duplication, and keyword stuffing. Do not recommend casual URL changes unless the plan includes 301 redirects, internal-link updates, canonical updates, sitemap updates, and rollback conditions.
- Whether main content appears in initial HTML or can render reliably. When important content depends only on client-side JavaScript, recommend verification with URL Inspection, rendering tests, and server-side rendering or prerendering options.
- Discoverable broken links, 404s, soft 404s, and incorrect internal destinations. A single URL cannot prove that a whole site has no broken links.
### B. Page structure and metadata
Check:
- A unique, accurate, intent-matched title. For Latin-script languages, a rough 50-60 characters can be useful, but accuracy matters more than reaching a count.
- A unique meta description that describes the page's real value without keyword lists or false promises. A meta description is not a ranking guarantee; prioritize relevance and likely click-through appeal.
- One H1 that describes the page's main question. Organize H2 and H3 headings by real topic hierarchy, without skipped levels or decorative text disguised as headings.
- `lang`, viewport, mobile usability, the ratio of main content to template noise, and breadcrumb visibility and semantics.
- Appropriate image formats, dimensions, lazy loading, and specific alt text. Decorative images should have empty alt text. Do not force keywords into alt text.
When recommending a rewrite, provide one adoptable title, meta description, H1, and heading outline. Label any information that needs a brand-owner confirmation.
### C. Structured data and trust signals
Check whether visible page content and JSON-LD, Microdata, or RDFa agree. Consider only schema appropriate to the page type: `BreadcrumbList`, `Article` or `BlogPosting`, `Product`, `SoftwareApplication`, `Organization`, `LocalBusiness`, `FAQPage`, and `WebPage`.
- Recommend schema only when it represents visible, real page information. Never add invented ratings, reviews, prices, authors, FAQs, or awards.
- Identify required fields such as URL, name, description, image, author, publish date, `dateModified`, breadcrumb positions, and entity identifiers.
- For content pages, check visible author information, author page or experience, editorial policy, sources, contact information, organization information, update date, and factual citations. E-E-A-T is not a tag that can be added; it comes from verifiable content and entity information.
- When schema exists, recommend the Google Rich Results Test and Schema Markup Validator as acceptance checks.
### D. Content, intent, and duplication
Identify the page's main query intent: informational, commercial research, transactional, local, navigational, or mixed. Check whether the main content answers the question early and adds value through original evidence, examples, steps, data, or product detail.
- Flag clear thin content, template repetition, unanswered core questions, intent mismatch, and stale content. Do not define thin content by word count alone.
- A single URL cannot prove site-wide duplicate content, keyword cannibalization, or orphan pages. Explain that these require a URL inventory, canonical and index status, GSC query-to-page data, an internal-link graph, and similarity analysis.
- For overlapping pages, first define the evidence and decision criteria for keep, merge, split, or redirect. Never recommend deleting a page based on a guess.
- When content creation is requested, provide a search-intent brief, unique value, information architecture, sources needed for claims, and internal-link targets. Original content means independent insight or verification, not a competitor rewrite.
- Suggest comparison, alternatives, list, or FAQ pages only when they have distinct intent, real comparison criteria, and maintainable facts. Do not create batches of low-value templates.
### E. Internal links, architecture, and topic coverage
Assess how the page can be found and understood:
- Check whether important pages have crawlable HTML links from relevant parent pages, topic hubs, navigation, or breadcrumbs. Anchor text should naturally describe the destination.
- Mark orphan pages as `Needs data` unless a sitemap and full link graph prove the finding.
- For a topic cluster, define one pillar or owner URL, a distinct intent for each support page, link direction, and a cannibalization rule. Multiple near-identical owner pages should not compete for one head topic.
- Before suggesting feature, use-case, integration, comparison, alternatives, or FAQ pages, define the user question, target query, unique content, owner URL, and link-back path.
### F. Performance, mobile use, and Core Web Vitals
Separate lab data from field data. Prefer real-user data from CrUX or PageSpeed Insights to validate LCP, INP, and CLS. Without it, inspect obvious risks: oversized hero media, images without dimensions, render-blocking CSS or JavaScript, third-party scripts, font loading, layout shifts, and heavy client-side rendering.
Every performance recommendation must explain its mechanism and test method. For example: responsive, compressed hero media may improve LCP; image width and height reduce CLS risk; splitting long tasks may improve INP. Do not promise a score or ranking improvement.
### G. Search performance, keywords, and external authority
Unless the user supplies data or access, mark these items as `Needs data`:
- Page-two rankings, traffic or ranking declines, and query-to-page keyword cannibalization.
- URLs or queries with high impressions and low CTR, plus title and meta tests.
- High-volume, low-difficulty keywords, SERP and People Also Ask opportunities, competitor gaps, and search intent.
- High-quality backlinks, broken-link opportunities, brand mentions, Google Business Profile, and local citations.
- GSC or Bing sitemap submission, URL Inspection, index coverage, and crawl errors.
Give an executable data-checking instruction. For example: in GSC, compare the last 28 days with the previous 28 days, filter to the target URL, export queries, impressions, clicks, CTR, and average position, then test a new title or meta description for high-impression, same-intent queries with weak CTR. Link strategies must use audience-relevant, editorially independent, verifiable channels and genuinely useful assets.
## Default deliverable format
Unless the user asks for a shorter response, return these sections in this order:
1. `Scope and limits`: target URL, check date, accessibility, what could not be verified, and key assumptions.
2. `Executive summary`: the three to seven most important findings and what to address first.
3. `Check matrix`: status, evidence, and short conclusion for items A-G. Cover the user's supplied checklist, and state `Needs data` where necessary.
4. `Prioritized action list`: P0-P3 tasks with owner, effort (S/M/L), acceptance criteria, and dependencies.
5. `Implementation-ready recommendations`: where appropriate, include metadata, heading structure, JSON-LD templates, internal-link locations, content briefs, or performance fixes.
6. `Data and human follow-up`: needed GSC, Bing, crawl, log, keyword, and business inputs, plus exact validation steps.
Use careful language. Say a change may improve relevance, discoverability, or CTR. Do not promise indexing, first place rankings, or that every SEO issue has been fixed.
## Completion standard
Before delivering the work, confirm:
- Every conclusion has public evidence or is explicitly labeled as an assumption or `Needs data`.
- Tasks are ordered by impact, dependency, and actual executability, not copied mechanically from a checklist.
- Recommendations do not risk breaking URLs, canonicals, index status, or content facts. Migration, deletion, and merge suggestions include redirect and rollback conditions.
- Schema and E-E-A-T recommendations come from visible facts or are clearly marked as information still needed.
- The report makes clear that no live changes, submissions, or publishing actions were performed.
Simpan berkas, lalu mulai ulang atau muat ulang Codex jika konfigurasi Anda memerlukannya. Tanyakan: Daftarkan skill yang tersedia di repository ini. Apakah seo-auto-optimizer tersedia? Jangan mulai tutorial sebelum Codex mengonfirmasi skill tersedia.
Tambahkan aturan repository minimal, hanya jika AGENTS.md belum ada
Jika repository tidak memiliki AGENTS.md, buat berkas kecil ini di root sebelum implementasi pertama. Jika sudah ada, pertahankan instruksinya dan minta Codex menambahkan aturan hanya setelah Anda menyetujuinya.
# Aturan otomatisasi SEO
- Baca struktur website yang ada sebelum mengubah berkas.
- Gunakan seo-auto-optimizer untuk rekomendasi yang berbasis bukti.
- Sebelum mengedit, sebutkan setiap berkas yang akan diubah dan tunggu persetujuan.
- Jangan mengubah URL, redirect, robots.txt, noindex, canonical tag, sitemap, atau deployment tanpa persetujuan eksplisit untuk perubahan tersebut.
- Tampilkan Git diff dan jalankan pemeriksaan repository yang relevan setelah perubahan disetujui.
- Jangan deploy, commit, atau push tanpa permintaan eksplisit.
Ini bukan konfigurasi SEO. Aturan ini menjaga batas peninjauan di repository, termasuk ketika Anda melanjutkan pekerjaan beberapa hari kemudian.
Periksa halaman sebelum meminta Codex mengubah apa pun
Buka Codex dan tempel prompt ini. Ganti URL contoh dengan URL halaman Anda.
Gunakan $seo-auto-optimizer untuk memeriksa halaman ini:
https://example.com/your-page
Saya baru mengenal SEO. Jelaskan setiap temuan dengan bahasa sederhana.
Jangan mengubah berkas, menerbitkan halaman, mengirim apa pun, atau membuat perubahan pada website live.
Untuk setiap rekomendasi, tunjukkan:
1. Apa yang ditemukan Codex dan lokasinya.
2. Mengapa hal itu penting bagi pengunjung atau mesin pencari.
3. Apakah itu masalah yang terkonfirmasi, peluang perbaikan, atau memerlukan data tambahan.
4. Tindakan berikutnya yang paling aman.
5. Apakah saya membutuhkan developer atau data Google Search Console.
Urutkan pekerjaan menurut prioritas: P0, P1, P2, lalu P3.
Hasil pertama seharusnya berupa laporan, bukan website yang berubah. Itulah hasil yang benar. Codex biasanya dapat memeriksa title halaman, meta description, heading utama, alt text gambar, tautan internal, canonical tag, instruksi robots, data terstruktur, viewport mobile, dan tautan rusak yang jelas. Codex juga dapat menemukan kekosongan konten yang jelas pada level halaman.
Codex tidak boleh mengklaim mengetahui semuanya. Laporan yang menyatakan "memerlukan data" sering kali lebih dapat dipercaya daripada laporan yang mendiagnosis seluruh situs dengan yakin hanya dari satu URL.
Baca laporan tanpa harus menjadi ahli SEO
Skill memakai dua label sederhana: status dan prioritas. Baca keduanya sebelum menyetujui apa pun.
| Label | Artinya | Respons ramah pemula |
|---|---|---|
|
| Bukti publik menunjukkan poin ini sudah baik. | Biarkan saja. |
|
| Codex menemukan masalah tertentu, seperti H1 yang hilang atau tautan salah. | Tinjau buktinya dan pertimbangkan perbaikan. |
|
| Halaman tidak rusak, tetapi dapat dibuat lebih jelas atau lebih berguna. | Anggap sebagai peningkatan opsional. |
|
| Codex memerlukan GSC, Bing, analytics, log, atau crawl lengkap. | Jangan menebak; kumpulkan datanya nanti. |
Prioritas menentukan apa yang perlu dilihat terlebih dahulu:
| Prioritas | Arti sederhana | Contoh umum |
|---|---|---|
|
| Masalah serius mungkin menghentikan halaman penting muncul atau bekerja dengan baik. |
|
|
| Struktur, intent, atau pengaturan teknis halaman memiliki kelemahan berarti. | Title dan H1 hilang atau bertentangan, intent salah, schema relevan tidak valid, atau tautan internal penting hilang. |
|
| Peningkatan yang bernilai, tetapi bukan keadaan darurat. | Alt text lebih baik, FAQ lebih jelas, informasi penulis atau pembaruan, pengujian title dan deskripsi. |
|
| Pekerjaan yang memerlukan data, tim lain, atau eksperimen berkelanjutan. | Mendapatkan tautan, profil lokal, pemantauan peringkat, atau riset kata kunci. |
Jangan menyetujui semua item hanya karena muncul di laporan. Implementasi pertama sebaiknya berisi satu hingga tiga perubahan berisiko rendah. Rilis kecil lebih mudah diperiksa dan lebih mudah dibatalkan.
Pilih perubahan pertama yang aman, tunda keputusan berisiko
Sebagian besar pemula dapat mulai dengan peningkatan halaman yang jelas. Tabel berikut membantu menetapkan batas.
| Biasanya aman disiapkan dan ditinjau | Berhenti dan minta tinjauan teknis atau SEO |
|---|---|
| Title atau meta description yang lebih akurat | Mengubah URL atau menghapus halaman |
| Satu H1 jelas dan H2 yang masuk akal | Mengedit |
| Alt text khusus untuk gambar yang bermakna | Aturan redirect atau pengaturan migrasi |
| Tautan internal rusak dengan tujuan benar yang jelas | Menggabungkan halaman karena tampak mirip |
| Schema yang menggambarkan konten terlihat dan terverifikasi | Menambahkan rating, ulasan, harga, penulis, atau FAQ yang tidak nyata |
| Jawaban singkat yang memperjelas halaman yang ada | Menerbitkan banyak halaman AI untuk mengejar kata kunci |
Canonical tag memberi tahu mesin pencari versi mana dari halaman serupa yang dianggap utama. Mengubahnya bisa penting, tetapi juga dapat membuat Google mengabaikan halaman yang Anda butuhkan. Minta Codex menampilkan URL canonical saat ini dan usulan URL baru, lalu minta tinjauan teknis sebelum mengubahnya. Aturan yang sama berlaku bagi robots.txt dan noindex: keduanya dapat benar untuk halaman terima kasih, pratinjau privat, atau hasil yang difilter.
Minta rencana implementasi, bukan perubahan mengejutkan
Salin item yang Anda setujui dari laporan, lalu gunakan prompt berikut di dalam proyek website.
Saya hanya menyetujui perubahan SEO ini:
[TEMPELKAN ITEM YANG DISETUJUI]
Tinjau proyek website lokal saya dan buat rencana implementasi. Sebelum mengubah berkas apa pun, tunjukkan setiap berkas yang akan diubah, halaman atau komponen yang terpengaruh, perubahan yang akan dilihat pengunjung dan mesin pencari, cara menguji hasil, serta cara rollback bila perubahan salah.
Jangan mengubah URL, menghapus halaman, mengedit robots.txt, menambah tag noindex, mengubah redirect, menerbitkan konten, melakukan deployment, atau melakukan perubahan di luar daftar yang disetujui.
Tunggu persetujuan saya setelah menunjukkan rencana.
Periksa daftar berkas sebelum menjawab. Jika Codex ingin menyentuh berkas yang tidak Anda kenali, tanyakan alasannya. Jika rencana hanya berkata "optimalkan SEO" tanpa menyebut berkas dan hasil yang diharapkan, minta Codex lebih spesifik.
Saat rencana sudah benar, berikan persetujuan yang sempit:
Disetujui. Terapkan hanya rencana di atas.
Setelah mengedit, berikan ringkasan singkat per berkas, tampilkan diff atau teks sebelum-dan-sesudah yang relevan, jelaskan apa yang perlu saya periksa secara manual, jalankan pemeriksaan proyek yang tersedia, dan jangan deploy.
Inilah bagian yang membuat otomatisasi berguna. Codex dapat melakukan perubahan berulang, tetapi Anda tetap memutuskan apa yang berubah dan kapan diterbitkan.
Periksa hasil sebelum halaman live
Jangan melewati pratinjau. Perubahan yang sah secara teknis masih dapat terdengar aneh, merusak tata letak, atau membuat halaman kurang berguna.
| Pemeriksaan | Yang perlu dilihat |
|---|---|
| Pratinjau browser | Halaman dimuat dan teks yang diubah terasa alami. |
| Pratinjau mobile | Heading, gambar, menu, dan tombol masih berfungsi pada layar sempit. |
| Title dan deskripsi | Keduanya menggambarkan halaman sebenarnya dan tidak menjanjikan sesuatu yang tidak didapat pengunjung. |
| Struktur heading | Satu H1 jelas menjelaskan halaman; H2 mengatur bagian yang nyata. |
| Tautan | Tautan internal yang diubah menuju halaman live atau staging yang benar. |
| Gambar | Gambar penting memiliki alt text berguna; gambar dekoratif tidak memiliki alt text penuh kata kunci. |
| Source atau ekstensi SEO | Canonical, instruksi robots, dan data terstruktur yang diharapkan tidak berubah tanpa sengaja. |
| Pemeriksaan proyek | Perintah build, test, lint, atau validasi yang tersedia berhasil. |
Untuk perubahan schema, jalankan Google Rich Results Test atau Schema Markup Validator setelah deployment, atau terhadap staging yang dapat diakses. Format schema yang valid saja tidak cukup; schema juga harus cocok dengan yang benar-benar dilihat pengguna.
Jika pemeriksaan gagal, jangan meminta Codex membuat perubahan lanjutan secara acak. Berikan error yang tepat, jelaskan perubahan yang disetujui sebagai penyebabnya, dan minta perbaikan sekecil mungkin. Jika Anda tidak dapat menjelaskan atau memvalidasi perubahan, batalkan sebelum deployment.
Yang tidak dapat diketahui otomatisasi SEO dari satu halaman
Di sinilah pemula sering disesatkan oleh keluaran AI yang terdengar yakin. Sebagian pertanyaan SEO memerlukan data yang tidak terlihat di browser.
| Pertanyaan | Yang diperlukan Codex untuk menjawab dengan bertanggung jawab |
|---|---|
| Mengapa trafik turun? | Data GSC dan analytics untuk dua periode yang dapat dibandingkan. |
| Halaman mana yang memiliki impresi tinggi tetapi CTR rendah? | Ekspor kueri dan halaman dari GSC. |
| Apakah dua halaman bersaing untuk kata kunci yang sama? | Data kueri-ke-halaman GSC dan perbandingan konten. |
| Halaman mana yang orphan? | Crawl situs lengkap, sitemap, dan grafik tautan internal. |
| Apakah Core Web Vitals benar-benar gagal bagi pengunjung? | Data lapangan seperti CrUX atau PageSpeed Insights, bukan hanya tes lokal. |
| Kata kunci kesulitan rendah mana yang harus ditargetkan? | Riset kata kunci dan SERP serta pemahaman audiens dan penawaran Anda. |
| Haruskah mengirim sitemap atau meminta indexing? | Akses GSC atau Bing Webmaster Tools dan alasan untuk melakukannya. |
Anda dapat mengotomatiskan pengumpulan dan pengorganisasian input ini nanti. Untuk halaman pertama, cukup minta Codex menandainya sebagai Needs data, bukan mengubah tebakan menjadi diagnosis.
Rutinitas mingguan yang sederhana
Setelah halaman pertama live dan diperiksa, ulangi alur ini pada satu halaman penting setiap minggu:
- Pilih halaman dengan tujuan bisnis, bukan URL acak.
- Jalankan pemeriksaan Codex baca-saja.
- Setujui hanya beberapa pembaruan yang jelas dan berisiko rendah.
- Tinjau rencana implementasi dan diff berkas.
- Uji secara lokal atau pada staging sebelum deployment.
- Catat halaman, tanggal, perubahan, dan pertanyaan terbuka dalam spreadsheet atau berkas Markdown sederhana.
Setelah beberapa minggu, tambahkan ekspor GSC. Codex kemudian dapat membantu menemukan halaman yang peningkatan berikutnya didukung impresi, klik, atau data kueri nyata. Untuk diagnosis yang lebih luas, gunakan juga pemeriksa skor SEO website bersama peninjauan tingkat kode.
FAQ
Apakah Codex dapat mengotomatiskan seluruh SEO website saya?
Tidak. Codex dapat mengotomatiskan pekerjaan berulang seperti meninjau sinyal halaman publik, menyusun daftar masalah, membuat draf title dan deskripsi, menyiapkan perubahan kode atau konten, serta memeriksa daftar perubahan yang disetujui. Keputusan tentang penghapusan halaman, redirect, kontrol indexing, canonical, klaim bisnis, deployment, atau data performa tetap membutuhkan peninjauan manusia.
Apakah saya harus memahami kata kunci SEO sebelum mulai?
Tidak. Mulailah dari halaman penting dan minta Codex menjelaskan pengaturan SEO yang terlihat dengan bahasa biasa. Riset kata kunci berguna ketika Anda ingin membuat halaman baru atau menentukan halaman lama yang layak dikerjakan. Riset membutuhkan data dan pemahaman pelanggan, bukan sekadar daftar yang dibuat agen.
Dapatkah Codex mengedit halaman WordPress, Webflow, atau Shopify untuk saya?
Hanya jika lingkungan Codex Anda memiliki akses resmi ke sistem tersebut atau berkas websitenya. Untuk alur pertama, minta Codex menyiapkan teks, kode, atau perubahan tingkat berkas yang tepat; kemudian lakukan pembaruan CMS sendiri atau minta pemilik situs menyetujuinya. Jangan memberikan akses publikasi sebelum proses peninjauan Anda andal.
Apakah perubahan ini membuat halaman saya menjadi nomor satu di Google?
Tidak. Perubahan SEO dapat meningkatkan crawlability, relevansi, kejelasan, dan pengalaman pengguna. Peringkat juga bergantung pada persaingan, search intent, kualitas situs, tautan, dan cara mesin pencari mengevaluasi halaman dari waktu ke waktu. Gunakan Codex untuk mengambil keputusan yang lebih baik dan lebih aman, bukan sebagai jaminan peringkat.
Penulis: Julian Mercer, praktisi Technical SEO selama 14 tahun di Auspia. Julian menulis tentang crawlability, schema, rendering, arsitektur situs, dan fondasi teknis untuk konten yang mudah dibaca AI.
