SEO para sa mga AI-Built na Website: Ano ang Talagang Mahalaga
Puwedeng ma-rank nang kasing-ganda ng kahit anong website ang AI-built na website: hinuhusgahan ng search engine kung ano ang laman ng pahina at kung gaano ito nakakatulong sa bisita, hindi kung aling tool ang sumulat ng code. Ang problema ay teknikal. Maraming AI builder ang gumagawa ng single-page app na nagpapadala sa browser ng halos walang lamang HTML file at gumuguhit ng nilalaman gamit ang JavaScript, na nagpapahirap sa bawat pahina na basahin at ibahagi ng mga crawler. Ayusin ito gamit ang prerendering o server rendering, bigyan ang bawat pahina ng sariling title, description at URL, magdagdag ng sitemap, panatilihing mabilis ito, at pagkatapos ay gawin ang bahaging hindi kayang gawin ng kahit anong tool para sa iyo: sumulat ng nilalamang hinahanap ng mga tao.
Bakit maaaring mahirapan ang single-page app sa search
Nagpapadala ang tradisyonal na website ng buong teksto ng bawat pahina sa HTML nito. Nagpapadala ang single-page app (SPA) — ang karaniwang output ng maraming AI builder, kadalasang React na may kasamang Vite — ng maliit na HTML shell, gaya ng walang lamang <div id="root">, kasama ang JavaScript bundle. Pinapatakbo ng browser ang JavaScript, na siyang bumubuo ng pahina.
Mahalaga ito sa search sa tatlong paraan:
- Dagdag na hakbang ang rendering. Inilalarawan ng Google ang tatlong yugto para sa JavaScript na pahina: i-crawl ang HTML, i-render ito sa headless na Chromium browser, at saka i-index ang na-render na resulta. Sinasabi ng sariling gabay ng Google na magandang ideya pa rin ang server-side rendering o prerendering dahil mas mabilis ito para sa user at crawler, at dahil hindi lahat ng bot ay kayang tumakbo ng JavaScript.
- Hindi nagre-render ang iba pang bumabasa ng pahina mo. Ang link preview sa chat app at social network, at maraming iba pang crawler, ay kadalasang binabasa lang ang paunang HTML. Kung ang title at preview image mo ay itinatakda ng JavaScript pagkatapos mag-load, ang ipapakita sa preview ay ang default ng walang lamang shell, kadalasan ay iisang title para sa lahat ng pahina.
- Iisang HTML file ang pinagsasaluhan ng lahat. Maliban kung i-update ito ng app, pareho ang
<title>at description ng bawat URL, na halos walang sinasabi sa search engine tungkol sa bawat pahina.
Hindi ibig sabihin nito na hindi ma-i-index ang SPA. Ibig sabihin nito, umaasa ka sa crawler na gumawa ng mas maraming trabaho, at nawawala sa iyo ang kontrol sa kung ano ang nakikita ng mga non-rendering na mambabasa.
Pumili ng paraan ng rendering
May apat na karaniwang paraan para makakuha ng totoong HTML ang mga crawler. Nakaayos ayon sa kung gaano nito binabago ang app mo:
| Paraan | Paano ito gumagana | Angkop para sa | Kapalit |
|---|---|---|---|
| Static na site | Ginagawa nang maaga ang mga pahina bilang plain HTML file | Marketing site, portfolio, docs, blog | Hindi gaanong angkop sa mga pahinang naka-log in o personalized |
| Prerendering (static site generation) | Sa build time, ina-render ang bawat public route bilang HTML file; ang JavaScript ang bahala sa browser pagkatapos | SPA na may kilalang set ng public na pahina | Nag-a-update lang ang pahina kapag nag-rebuild ka |
| Server-side rendering (SSR) | Nagre-render ang server ng HTML sa bawat request (Next.js, Remix, Nuxt at katulad) | Malaki o madalas magbagong public na nilalaman, halimbawa mga listing | Kailangan ng tumatakbong server; mas maraming gumagalaw na bahagi |
| Dynamic rendering | Naghahain ng prerendered na HTML sa mga bot at SPA sa mga tao | Lumang workaround | Tinatawag na ng Google na workaround, hindi pangmatagalang solusyon, at inirerekomenda nito ang SSR, static rendering o hydration sa halip |
Praktikal na tuntunin: ang publiko at mahahanap na bahagi ng site mo ay dapat static o prerendered; ang app sa likod ng log-in ay puwedeng manatiling normal na SPA. Hindi dapat ina-index ng search engine ang mga dashboard naman.
Kung nagsisimula ka sa wala at mahalaga ang SEO, sabihin ito sa unang prompt para mapili ng AI ang angkop na setup:
Gumawa ng marketing site para sa isang physiotherapy clinic na may mga pahinang Home, Services (isang pahina bawat serbisyo), About, Pricing at Contact. Mahalaga ang SEO: bawat pahina ay dapat magpadala ng buong nilalaman at sariling title at meta description sa paunang HTML — gumamit ng static o prerendered na setup, hindi client-only na single-page app.
Kung mayroon ka nang Vite SPA, hilingin ang prerendering ng mga public route:
Panatilihin ang React app na ito gaya ng dati, pero i-prerender ang mga public route (/, /pricing, /about, /blog at bawat /blog/:slug) bilang static HTML sa build time, bawat isa ay may sariling title, meta description, canonical URL at Open Graph tag. Puwedeng manatiling client-rendered ang mga /app route na naka-log in.
Pagkatapos, suriin mo mismo ang resulta: buksan ang isang pahina, piliin ang View page source (hindi ang Elements panel ng dev tools, na nagpapakita ng na-render na pahina), at kumpirmahing nasa raw HTML ang teksto at title.
Ayusin ang mga batayan sa pahina
Naaangkop ang mga ito anuman ang paraan ng rendering.
Mga title at meta description
- Isang natatanging
<title>bawat pahina, na nauuna ang pangunahing paksa. Karaniwang gabay ang humigit-kumulang 50–60 karakter dahil madalas maputol ang mas mahahabang title sa mga resulta. - Isang natatanging meta description bawat pahina: isang pangungusap na gugustuhing i-click ng tao, hindi listahan ng keyword. Puwedeng isulat muli ng Google, pero madalas itong ginagamit kapag maganda.
- Laktawan ang meta keywords. Sinabi ng Google na walang epekto ang tag na ito sa indexing o ranking.
URL, heading at link
- Totoong URL para sa totoong pahina. Kailangan ng bawat piraso ng nilalaman ng sariling path (
/services/sports-massage), hindi tab o modal na umiiral lang pagkatapos mag-click. Iwasan ang#fragment routing para sa nilalamang gusto mong ma-index. - Isang
h1bawat pahina, saka sunod-sunod nah2/h3na outline. Minsan ginagamit ng mga AI-generated na disenyo ang heading para sa istilo; humiling ng semantic heading. - Mga link na nakikita ng crawler. Gumamit ng totoong
<a href>na link para sa navigation. Ang mga button na nagpapalit ng pahina gamit ang JavaScript ay hindi nakikita ng mga crawler na sumusunod sa link. - Canonical tag na tumuturo sa bawat pahina sa gusto nitong URL, para hindi maglaban ang mga
?utm=variant at trailing-slash na duplicate. - Malinaw na alt text sa mga makabuluhang larawan.
Social preview
Magdagdag ng Open Graph tag (og:title, og:description, og:image, og:url) sa bawat public na pahina, sa paunang HTML. Ito ang bahaging pinakamadalas na napapalpak ng mga SPA, dahil hindi tumatakbo ng JavaScript ang mga link preview bot.
Sitemap at robots.txt
Ang sitemap ay XML file na naglilista ng mga URL na gusto mong i-index. Nakakatulong ito sa search engine na mahanap ang mga pahina, lalo na sa mga bagong site na kakaunti ang papasok na link. Ayon sa dokumentasyon ng Google, noong Setyembre 2026:
- Hanggang 50,000 URL o 50 MB na hindi naka-compress ang kayang laman ng isang sitemap; hatiin ang mas malalaking site gamit ang sitemap index.
- Binabalewala ng Google ang
<priority>at<changefreq>. - Ginagamit lang ng Google ang
<lastmod>kung palagi itong tumpak, kaya i-update ito para sa tunay na pagbabago ng nilalaman, hindi sa bawat build.
Ang robots.txt ay file na nagsasabi sa mga crawler kung aling path ang hindi dapat i-crawl. Gamitin ito para ilayo ang mga crawler sa /app, /admin at API route, at ituro ang sitemap mula rito. Tandaan na pinipigilan ng robots.txt ang crawling, hindi ang indexing: para mailayo ang pahina sa mga resulta, gumamit ng noindex robots meta tag at hayaang ma-crawl ito.
Isumite ang sitemap sa Google Search Console kapag nasa huling domain na ang site. Ipinapakita rin ng Search Console kung aling pahina ang naka-index at kung bakit ang iba ay hindi — ito ang pinakamahalagang libreng SEO tool na mayroon.
Structured data
Ang structured data ay machine-readable na markup na naglalarawan kung ano ang pahina: isang organisasyon, lokal na negosyo, produkto, artikulo, o event. Inirerekomenda ng Google ang format na JSON-LD at malinaw sa dalawang punto:
- Puwedeng gawing karapat-dapat ang pahina sa rich result pero hindi nito ginagarantiya ang mga iyon.
- Dapat nitong ilarawan ang impormasyong nakikita sa pahina. Huwag mag-markup ng mga review, presyo o FAQ na hindi nakikita ng bisita.
Mga magandang panimulang punto: Organization o LocalBusiness sa homepage, Product sa mga pahina ng produkto, Article sa mga blog post, BreadcrumbList sa mga malalalim na pahina. Subukan gamit ang Rich Results Test ng Google.
Magdagdag ng JSON-LD structured data: LocalBusiness sa homepage gamit ang address, telepono at oras ng bukas na nakikita na sa pahina, at Article sa bawat blog post. Huwag magdagdag ng rating o review.
Bilis at mobile
Gumagamit ang Google ng page experience signal, kasama ang Core Web Vitals, at mahalaga ang bilis sa mga bisita anuman ang mangyari. Ang "magandang" threshold ng Google, na sinusukat sa ika-75 percentile ng mga page load, ay:
| Metric | Sinusukat | Maganda |
|---|---|---|
| Largest Contentful Paint (LCP) | Gaano kabilis lumitaw ang pangunahing nilalaman | 2.5 s o mas mababa |
| Interaction to Next Paint (INP) | Gaano kabilis tumugon ang pahina sa input | 200 ms o mas mababa |
| Cumulative Layout Shift (CLS) | Gaano kalaki ang paggalaw ng layout habang nagloload | 0.1 o mas mababa |
Ang mga karaniwang ayos para sa AI-built na site:
- Mga larawan: i-resize, i-compress, gumamit ng modernong format, itakda ang width at height (pumipigil ito sa layout shift), at i-lazy-load ang nasa ibaba ng fold.
- JavaScript: nagpapabagal sa lahat ang malaking bundle sa SPA. Nakakatulong ang prerendering; nakakatulong din ang paghahati ng code kada route.
- Font: limitahan ang bilang ng family at weight at i-preload ang ginagamit sa itaas ng fold.
- Third-party script: bawat chat widget at tracking pixel ay may kapalit na bilis. Panatilihin lang ang mga ginagamit mo.
Subukan ang live URL gamit ang PageSpeed Insights o Lighthouse sa mobile mode.
Nilalaman pa rin ang pinakamahalaga
Inaalis ng teknikal na SEO ang mga balakid; hindi nito ginagawang demand ang wala. Nararanggo ang mga pahina dahil mas mahusay nilang sinasagot ang isang paghahanap kaysa sa mga alternatibo. Para sa karamihan ng maliliit na site, ibig sabihin nito:
- Isang pahina bawat paksang hinahanap ng mga tao. Ang tubero ay nangangailangan ng pahina bawat serbisyo at bawat lugar na sakop, hindi iisang pahinang "Services" na naglilista ng lahat.
- Tiyak at orihinal na detalye: presyo, proseso, litrato ng totoong trabaho, sagot sa mga tanong na itinatanong ng customer sa telepono.
- Ina-update kapag may nagbago. Mabilis mawalan ng tiwala ang lumang oras at lumang presyo.
Mabilis gumawa ng draft ng pahina ang AI, kaya nakakaakit ang mag-publish ng maraming manipis at magkakatulad na pahina. Ang gabay ng Google ay tumatarget sa nilalamang ginawa higit sa lahat para ma-rank kaysa tumulong sa tao, anuman ang paraan ng paggawa. Gamitin ang AI sa pag-draft, pagkatapos ay idagdag ang alam mo lang. Pinakamaraming naaapektuhan dito ang mga directory-style na site; tingnan ang paano gumawa ng directory website para malaman kung paano gawing sulit i-index ang mga listing page.
Checklist bago ilunsad
- Ang mga public na pahina ay nagpapadala ng buong nilalaman sa paunang HTML (suriin gamit ang View page source)
- Natatanging title, meta description at canonical URL sa bawat pahina
- Open Graph tag at share image sa bawat public na pahina
- Isang
h1bawat pahina, totoong<a href>na link, alt text sa mga larawan -
sitemap.xmlna may totoong URL;robots.txtna humaharang sa app at API path - Structured data para lang sa nakikitang nilalaman, nasubukan na
- Nasa "maganda" na range ang LCP, INP at CLS sa mobile
- Nasa huling domain na ang site na may HTTPS at naisumite sa Search Console
Ang paglipat sa sarili mong domain bago ka magsimulang bumuo ng search traffic ay umiiwas sa mga redirect sa hinaharap; tingnan ang paano ikonekta ang custom domain. Para sa mas malawak na proseso ng pagtatayo, basahin ang paano gumawa ng website gamit ang AI, at para sa mga pahinang layuning mag-convert ng bisita, ang paano gumawa ng landing page na nagko-convert.
SEO sa Mythex
Wala sa Mythex ang hiwalay na SEO panel; napapabuti mo ang SEO sa pamamagitan ng pagbabago ng app sa chat o code. Ang mga bagong web app ay default na Vite at React single-page app, kaya kapag mahalaga ang search, hilingin mula sa simula ang static o prerendered na site, o ang Next.js. Nasa docs ang starter prompt para sa mga title, Open Graph tag, sitemap at robots.txt sa SEO para sa app mo, at sakop ng static websites ang mga site na nakatutok sa nilalaman. Pagkatapos ng mga pagbabago, mag-publish ulit para makuha ng live na site ang mga ito. Available ang custom domain sa Pro.
Mga tanong
Masama ba sa SEO ang mga AI-built na website?
Hindi likas. Hinuhusgahan ng search engine ang pahina, hindi ang tool na sumulat nito. Ang karaniwang problema ay teknikal: maraming AI builder ang gumagawa ng single-page app na lumalabas lang ang nilalaman pagkatapos tumakbo ang JavaScript, at hindi ito maayos na nababasa ng ilang crawler. Naaayos ito ng prerendering o server rendering.
Kaya bang i-index ng Google ang React single-page app?
Kayang mag-render ng JavaScript ng Google, kaya kadalasan ay kaya nitong i-index ang client-rendered na React app. Pero dagdag na hakbang ang rendering, at sinasabi mismo ng Google na hindi lahat ng bot ay kayang tumakbo ng JavaScript, kaya inirerekomenda nito ang server-side rendering o prerendering kung kaya mo.
Mahalaga pa ba ang meta keywords?
Hindi na. Sinabi ng Google na hindi nito ginagamit ang meta keywords tag para sa indexing o ranking. Ilaan na lang ang pagsisikap sa natatanging title at meta description para sa bawat pahina.
Pinapabuti ba ng structured data ang ranking?
Nakakatulong ang structured data sa search engine na maintindihan ang pahina at maaaring maging karapat-dapat sa rich result, pero hindi nito ginagarantiya ang mga iyon. Dapat itong naglalarawan ng nilalamang talagang nakikita sa pahina.