Cara Mengotomatiskan SEO Website dengan Claude Code: Panduan Pemula

Anda tidak perlu memahami fungsi canonical tag sebelum memakai Claude Code untuk memperbaiki sebuah halaman. Anda memerlukan satu URL halaman, akses ke proyek website saat siap melakukan perubahan, dan satu aturan sederhana: Claude Code memeriksa terlebih dahulu; Anda menyetujui perubahan sesudahnya.

Panduan ini menunjukkan cara aman bagi pemula untuk mengotomatiskan pekerjaan SEO berulang dengan Claude Code dan skill seo-auto-optimizer. Anda akan meminta Claude Code 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 Claude Code;
• 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:

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 proyek Claude Code Anda

Anda perlu membuat berkas skill sendiri. Tidak ada lampiran yang perlu diunduh dari artikel ini.

Opsi tercepat: kirim artikel ini ke Claude Code

Setelah artikel ini dipublikasikan, Anda dapat memberikan URL-nya kepada Claude Code dan memintanya memasang skill. Salin prompt berikut, ganti [URL ARTIKEL] dengan URL artikel ini, lalu kirim ke Claude Code:

Baca artikel ini dan pasang skill seo-auto-optimizer persis seperti instruksinya:
[URL ARTIKEL]

Saya pemula. Temukan blok kode SKILL.md lengkap di artikel. Buat berkas .claude/skills/seo-auto-optimizer/SKILL.md di proyek ini, lalu salin blok kode itu persis ke dalam berkas tersebut.

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 Claude Code tidak dapat membuka URL artikel, gunakan cara manual di bawah. Jika perlu, Anda dapat menempelkan blok kode lengkap ke chat setelah prompt tersebut.

Di folder root proyek Claude Code, buat folder dan berkas berikut:

proyek-anda/
.claude/
skills/
seo-auto-optimizer/
SKILL.md

Nama folder dan nilai name di berkas harus sama-sama seo-auto-optimizer. Claude Code kemudian dapat memanggilnya dengan $seo-auto-optimizer. Path tutorial ini sengaja menggunakan .claude/skills/seo-auto-optimizer/SKILL.md.

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 Claude Code jika konfigurasi Anda memerlukannya. Tanyakan: Daftarkan skill yang tersedia di proyek ini. Apakah seo-auto-optimizer tersedia? Jangan mulai tutorial sebelum Claude Code mengonfirmasi skill tersedia.

Tambahkan kebijakan CLAUDE.md sebelum perubahan pertama

Claude Code memakai CLAUDE.md sebagai panduan proyek. Jika berkas ini sudah ada, tambahkan aturan berikut secara hati-hati dan jangan mengganti isinya. Jika belum ada, buat di root sebelum implementasi pertama.

# Otomatisasi SEO yang aman

Untuk tugas SEO, mulailah dengan pemeriksaan baca-saja menggunakan seo-auto-optimizer. Jelaskan temuan dengan bahasa sederhana dan beri label Needs data untuk temuan yang belum pasti. Sebelum mengedit, sediakan rencana tertulis berisi berkas terdampak, perubahan halaman yang diharapkan, pemeriksaan, dan cara rollback. Tunggu persetujuan eksplisit.

Jangan mengubah URL, robots.txt, noindex, canonical tag, redirect, sitemap, konfigurasi deployment, atau konten CMS tanpa persetujuan per perubahan. Setelah perubahan disetujui, tampilkan diff dan jalankan pemeriksaan lokal yang relevan. Jangan deploy, commit, atau push kecuali diminta.

Saat meminta perbaikan, mulailah dari permintaan khusus rencana di artikel ini. Baca rencananya. Jika terlalu luas, katakan: "revisi rencana agar hanya mengubah [berkas atau komponen]". Jeda singkat ini adalah perlindungan paling berguna bagi pengguna baru.

Periksa halaman sebelum meminta Claude Code mengubah apa pun

Buka Claude Code 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 Claude Code 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. Claude Code 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. Claude Code juga dapat menemukan kekosongan konten yang jelas pada level halaman.

Claude Code 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.

Prioritas menentukan apa yang perlu dilihat terlebih dahulu:

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.

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 Claude Code 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 Claude Code ingin menyentuh berkas yang tidak Anda kenali, tanyakan alasannya. Jika rencana hanya berkata "optimalkan SEO" tanpa menyebut berkas dan hasil yang diharapkan, minta Claude Code 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. Claude Code 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.

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 Claude Code 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.

Anda dapat mengotomatiskan pengumpulan dan pengorganisasian input ini nanti. Untuk halaman pertama, cukup minta Claude Code 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:

1. Pilih halaman dengan tujuan bisnis, bukan URL acak.
2. Jalankan pemeriksaan Claude Code baca-saja.
3. Setujui hanya beberapa pembaruan yang jelas dan berisiko rendah.
4. Tinjau rencana implementasi dan diff berkas.
5. Uji secara lokal atau pada staging sebelum deployment.
6. Catat halaman, tanggal, perubahan, dan pertanyaan terbuka dalam spreadsheet atau berkas Markdown sederhana.

Setelah beberapa minggu, tambahkan ekspor GSC. Claude Code 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 Claude Code dapat mengotomatiskan seluruh SEO website saya?

Tidak. Claude Code 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 Claude Code 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 Claude Code mengedit halaman WordPress, Webflow, atau Shopify untuk saya?

Hanya jika lingkungan Claude Code Anda memiliki akses resmi ke sistem tersebut atau berkas websitenya. Untuk alur pertama, minta Claude Code 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 Claude Code 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.