SEO البرمجي: كيف حصلنا على 253K صفحة مفهرسة باستخدام Next.js و Supabase

في العام الماضي، وصلنا إلى معلم لم أعتقد أنه ممكن حقاً: 253,000 صفحة برمجية مفهرسة عبر ثلاثة مواقع إنتاجية، تعمل جميعها على نفس المكدس. ليس مشروع لعبة. ليس عرضاً توضيحياً. مواقع حقيقية بحركة حقيقية وإيرادات حقيقية.

سأرشدك عبر كيفية بناء Deluxe Astrology (91,000 صفحة)، Not Another Sunday (137,000 قائمة مكان)، و HostList (25,000 ملف تعريف شركة استضافة) -- بما في ذلك استعلامات Supabase، معمارية صفحة Next.js، خطوط الأنابيب للبيانات، والأهم من ذلك، ما انكسر على طول الطريق. لأن الكثير انكسر.

معظم محتوى SEO البرمجي عبر الإنترنت يبدو وكأن شخصاً ما تصفح المستندات واستدعى يوماً واحداً. هذا ليس ذلك. كنا نشحن هذه الصفحات لأكثر من عام، مراقبين رسوم البيانات في Google Search Console، لعننا حدود ميزانية الزحف، وببطء اكتشاف ما يعمل بالفعل على نطاق واسع.

جدول المحتويات

SEO البرمجي: كيف حصلنا على 253K صفحة مفهرسة باستخدام Next.js و Supabase

ما يعنيه SEO البرمجي بالفعل في 2025

SEO البرمجي هو توليد صفحات على نطاق واسع من البيانات المنظمة باستخدام القوالب. هذه هي النسخة المكونة من جملة واحدة. الواقع أكثر فوضى بكثير.

موقف Google في 2025 واضح لكنه دقيق: لا يعاقبون محتوى برمجي لأنه برمجي. يعاقبونه عندما يكون رقيقاً أو مكراراً أو غير مفيد. الفرق بين 70,000 صفحة مفهرسة من Zapier تساهم في 140 مليون دولار ARR ودراسة حالة dev.to حيث حصلت 287,000 صفحة على فهرسة قريبة من الصفر يتوقف على شيء واحد -- ما إذا كانت كل صفحة تجيب حقاً على استعلام كتبه إنسان في شريط البحث.

تخبرنا بيانات Ahrefs أن 96.55% من جميع صفحات الويب لا تحصل على حركة عضوية. يضخم SEO البرمجي هذه المشكلة إذا كنت تنشئ فقط اختلافات من نفس المحتوى. لكن يمكنه أيضاً حلها بشكل مثير إذا كانت بيانتك فريدة حقاً وتنتج قوالبك صفحات مختلفة بشكل كبير عن بعضها البعض.

إليك نموذج عقلي يعمل بالنسبة لنا: يجب أن تمر كل صفحة برمجية باختبار "هل كنت سأضع هذا في الإشارات المرجعية؟". إذا هبطت عليها من Google، هل ستبقى؟ هل ستجد شيئاً لا يمكنك العثور عليه في مكان آخر؟ إذا كانت الإجابة لا، فلا تنشرها.

المشاريع الثلاثة: أرقام الإنتاج

دعني أوضح ما بنيناه بالفعل وكيف تبدو الأرقام.

المشروع الصفحات أنواع المحتوى النطاق الجغرافي المقياس الرئيسي
Deluxe Astrology 91,000 الأبراج، ملفات تعريف المشاهير، أرقام الملاك، العملات الكونية، الأحجار الكريمة، أوضاع اليوغا، معمل الأسماء، دليل المنجمين 30 لغة 91K صفحة مفهرسة
Not Another Sunday 137,000 قوائم مقاهي ومحمصات مع درجة NRI، صور، خرائط الولايات المتحدة، المملكة المتحدة، اليابان 137K صفحة مكان فريدة
HostList 25,000 ملفات تعريف شركات الاستضافة مع خوارزمية HostScore 53 دول 25K ملف تعريف مفهرس
الإجمالي 253,000

Deluxe Astrology: 91K صفحة عبر 30 لغة

بدأ Deluxe Astrology كموقع أبراج بلغة واحدة. جاء الحجم من تقاطع أنواع المحتوى والللغات. فكر بالأمر: إذا كان لديك 12 برج × 365 برج يومي × 30 لغة، فأنت بالفعل في 131,000 صفحة محتملة من نوع محتوى واحد فقط. كنا انتقائيين -- لا تحصل كل مجموعة على صفحة -- لكن الطبيعة التجميعية لمحتوى التنجيم مثالية لـ pSEO.

قسم ملفات تعريف المشاهير وحده يحتوي على 28,840 سجل، كل منها مثري عبر Claude ليشمل تحليل الخريطة الفلكية، تفاصيل الشخصية، وإحساسات التوافق. المزيد حول خط أنابيب البيانات هذا لاحقاً.

Not Another Sunday: 137K قائمة مكان

Not Another Sunday هي منصة اكتشاف القهوة المتخصصة. كل مقهى ومحمصة تحصل على صفحة فريدة مع درجة NRI (Neighbourhood Relevance Index) حكومية، صور مختارة بعناية، خريطة مدمجة، ساعات العمل، والمراجعات. نسحب البيانات من عدة واجهات برمجية، محتوى من المستخدمين، والمراجعة اليدوية.

الرؤية الرئيسية: لا صفحتا مقهى تبدو متطابقة لأن لا مقهيان متطابقان. القالب متسق، لكن البيانات تملأه بشكل مختلف في كل مرة. مقهى في Shibuya مع 4.8 NRI ومسابقات فن اللاتيه يبدو مختلفاً جداً عن محمصة في Brooklyn مع 3.2 NRI وعمليات بيع بالجملة فقط.

HostList: 25K ملف تعريف استضافة عبر 53 دول

HostList فهرس شركات استضافة في جميع أنحاء العالم، كل منها مع HostScore -- تقييمنا الخوارزمي بناءً على بيانات الحموضة، التسعير، استجابة الدعم، ومراجعات المستخدمين. 25,000 ملف تعريف عبر 53 دول، كل منها مع بيانات أداء فريدة، جداول التسعير، وعناصر المقارنة.

المكدس: Supabase و Next.js ISR و Vercel Edge

قمنا بتوحيد نفس المكدس عبر المشاريع الثلاثة. إليك سبب أهمية كل جزء.

Supabase (PostgreSQL + pgvector): طبقة البيانات كاملة لدينا تعيش في Supabase. يعطينا PostgreSQL البنية العلائقية التي نحتاجها للاستعلامات المعقدة (أعطني جميع نجوم القوس مشهير من ولدوا في ديسمبر وهم أيضاً موسيقيين)، و pgvector يقوي البحث الدلالي عبر المحتوى. طبقة Supabase المجانية تتعامل مع 500MB؛ نحن على Pro في $25/شهر لكل مشروع لـ 8GB قواعد بيانات مع استدعاءات API غير محدودة.

Next.js مع ISR (الإنشاء الثابت الإضافي): كل صفحة يتم إنشاؤها بشكل ثابت وقت البناء أو في الطلب الأول، ثم يتم التحقق من صحتها على جدول. هذا يعني أن زحف Google دائماً يضرب صفحة HTML محددة مسبقاً سريعة -- وليس دوار تحميل في انتظار JavaScript من جانب العميل. نستخدم App Router مع generateStaticParams لإنشاء المسار.

Vercel Edge: النشر و CDN و Edge Middleware كل شيء في واحد. خطة Vercel Pro في $20/مستخدم/شهر تعطينا 1TB النطاق الترددي، الذي يتعامل مع الحركة من 253K صفحة بشكل مريح. Edge Middleware يتعامل مع التوجيه الجغرافي لـ Deluxe Astrology بـ 30 لغة.

تكلفة البنية التحتية الإجمالية لجميع المشاريع الثلاثة تعمل حول $150–200/شهر. أنت تستضيف 253,000 صفحة تحصل على ملايين الزحف الشهري. إذا كنت تبني مواقع برمجية وتفكر في قدرات تطوير Next.js أو تحتاج إلى مساعدة في معمارية نظام إدارة المحتوى بدون رأس، هذا هو المكدس الذي سننصح به.

SEO البرمجي: كيف حصلنا على 253K صفحة مفهرسة باستخدام Next.js و Supabase - معمارية

معمارية خط أنابيب البيانات

البيانات هي ما يجعل أو يكسر SEO البرمجي. القوالب سهلة. الحصول على بيانات فريدة وعالية الجودة حقاً لعشرات الآلاف من الصفحات؟ هذا هو الجزء الصعب.

نستخدم أربعة أنواع مصادر بيانات عبر مشاريعنا:

1. كشط واجهة برمجية التطبيقات

لا تسحب Not Another Sunday بيانات المقام من Google Places API، Yelp Fusion API، وحفنة من واجهات برمجية الإقليمية لليابان. نشغل وظائف مزامنة ليلية عبر Supabase Edge Functions التي تتحقق من المقامات الجديدة والساعات المحدثة والمواقع المغلقة. يتم تطبيع كل رد استجابة API على مخطط قبل الإدراج.

2. استيراد CSV مع التحقق

جاءت مجموعة بيانات HostList الأولية من ملف CSV ضخم لشركات الاستضافة مجمعة على مدار سنتين. بنينا خط أنابيب للتحقق من الصحة يتحقق من البدلات، ويطبيع أسماء الشركات، ويضع علم على السجلات غير المكتملة. حوالي 30% من الاستيراد الأولي تم وضع علم عليه وتطلب مراجعة يدوية.

3. إثراء Claude AI

هنا يصبح مثيراً. بالنسبة لـ Deluxe Astrology، كان لدينا 28,840 سجل مشاهير مع بيانات سيرة ذاتية أساسية -- الاسم، تاريخ الميلاد، مكان الميلاد. هذا ليس كافياً لصفحة مفيدة. استخدمنا Claude (واجهة برمجية Anthropic) لإثراء كل سجل مع تفسير خريطة فلكية، تحليل شخصية، رؤى توافق الوظيفة، وحقائق مرحة.

المفتاح: لم نستخدم Claude لـ توليد محتوى من لا شيء. استخدمناه لـ تحليل وتفسير بيانات فلكية حقيقية. كل خريطة فلكية مشاهير محسوبة رياضياً من بيانات ولادتهم، ثم يوفر Claude التفسير الفلكي. البيانات الأساسية فريدة وقابلة للتحقق. طبقة AI تضيف عمقاً، وليس تزييفاً.

إليك نسخة مبسطة من خط أنابيب الإثراء الخاص بنا:

import anthropic
from supabase import create_client

client = anthropic.Anthropic()
supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

def enrich_celebrity(record):
    natal_chart = calculate_natal_chart(
        birth_date=record['birth_date'],
        birth_place=record['birth_place']
    )
    
    prompt = f"""Given this natal chart data for {record['name']}:
    Sun: {natal_chart['sun_sign']} in {natal_chart['sun_house']}
    Moon: {natal_chart['moon_sign']} in {natal_chart['moon_house']}
    Rising: {natal_chart['ascendant']}
    
    Write a 300-word astrological personality profile focusing on 
    how these placements manifest in their career as a {record['profession']}.
    Include specific aspect interpretations."""
    
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )
    
    supabase.table('celebrities').update({
        'natal_chart': natal_chart,
        'ai_profile': response.content[0].text,
        'enriched_at': 'now()'
    }).eq('id', record['id']).execute()

عالجنا جميع السجلات 28,840 على مدار حوالي أسبوع، حزم الطلبات للبقاء ضمن حدود معدل. كانت التكلفة تقريباً $180 في أرصدة API. ليس سيئاً لإثراء ما يقرب من 29K صفحة بمحتوى فريد.

4. محتوى من المستخدمين

Not Another Sunday تقبل المراجعات وتقديمات الصور من المستخدمين. يجعل UGC هذا الصفحات فريدة بشكل متزايد بمرور الوقت ويشير إلى Google أن المحتوى طازج ومدفوع بالمجتمع.

معمارية قالب الصفحة التي لا يكرهها Google

هنا حيث تفشل معظم مشاريع SEO البرمجية. إنهم ينشئون قالباً مثل:

<h1>{City} {Service} Directory</h1>
<p>Looking for {service} in {city}? Browse our directory of {count} providers.</p>

هذا محتوى رقيق. Google يعرف ذلك. المستخدمون يعرفون ذلك. لا تفعل هذا.

معمارية القالب الخاص بنا تضمن أن كل صفحة لها خمسة عناصر فريدة:

  1. H1 فريد: ليس فقط {name} مدرج في نمط. تتغير بنية H1 حسب نوع المحتوى وتتضمن معدلات سياقية.

  2. وصف ميتا فريد: مولد من بيانات الصفحة الفعلية، وليس قالب مع ملء في الفراغات.

  3. محتوى جسم فريد: هذا هو الكبير. لكل صفحة 400-2,000 كلمة من المحتوى المحدد للكيان ذي الصلة. بالنسبة للمشاهير، إنه تحليل خريطتهم الفلكية. بالنسبة للمقامات، إنها انهيار NRI، السياق المحيط، وملخصات القائمة. بالنسبة لشركات الاستضافة، إنه انهيار HostScore مع نسب وقت تشغيل محددة وجداول التسعير.

  4. البيانات المنظمة (schema.org): كل صفحة تحصل على علامات JSON-LD مناسبة لنوعها -- Person للمشاهير، LocalBusiness للمقامات، Organization لشركات الاستضافة.

  5. الربط الداخلي: كل صفحة ترتبط 5-15 صفحات ذات صلة بناءً على علاقات البيانات الفعلية. صفحة مشهور ترتبط بمشاهير آخرين من نفس علامة الشمس، نفس المهنة، أو نفس سنة الميلاد. صفحة مقام ترتبط بمقامات قريبة وصفحات بنقاط NRI مماثلة.

اتضح أن جزء الربط الداخلي هو أهم عامل واحد للفهرسة. المزيد حول ذلك في قسم الإصلاحات.

رمز حقيقي: من استعلام Supabase إلى صفحة معروضة

دعني أريك التدفق الفعلي لصفحة مقام Not Another Sunday. هذا هو رمز الإنتاج، مبسط قليلاً للقراءة.

أولاً، طبقة استعلام Supabase:

// lib/queries/venues.ts
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

export async function getVenueBySlug(slug: string) {
  const { data, error } = await supabase
    .from('venues')
    .select(`
      id, name, slug, description, nri_score,
      address, city, country, lat, lng,
      opening_hours, photos, menu_highlights,
      created_at, updated_at,
      venue_reviews (
        id, rating, body, author_name, created_at
      ),
      venue_tags (
        tag:tags ( name, slug )
      )
    `)
    .eq('slug', slug)
    .eq('status', 'published')
    .single()

  if (error) throw error
  return data
}

export async function getRelatedVenues(venueId: string, city: string, nriScore: number) {
  const { data } = await supabase
    .rpc('get_related_venues', {
      p_venue_id: venueId,
      p_city: city,
      p_nri_score: nriScore,
      p_limit: 12
    })

  return data ?? []
}

الدالة get_related_venues هي دالة PostgreSQL في Supabase التي ترجع مقامات قريبة مرتبة حسب قرب درجة NRI:

CREATE OR REPLACE FUNCTION get_related_venues(
  p_venue_id UUID,
  p_city TEXT,
  p_nri_score NUMERIC,
  p_limit INT DEFAULT 12
)
RETURNS TABLE (
  id UUID, name TEXT, slug TEXT, 
  nri_score NUMERIC, city TEXT, country TEXT
) AS $$
BEGIN
  RETURN QUERY
  SELECT v.id, v.name, v.slug, v.nri_score, v.city, v.country
  FROM venues v
  WHERE v.id != p_venue_id
    AND v.status = 'published'
    AND v.city = p_city
  ORDER BY ABS(v.nri_score - p_nri_score) ASC
  LIMIT p_limit;
END;
$$ LANGUAGE plpgsql;

الآن مكون صفحة Next.js باستخدام App Router:

// app/venues/[country]/[city]/[slug]/page.tsx
import { getVenueBySlug, getRelatedVenues } from '@/lib/queries/venues'
import { VenueHeader } from '@/components/venue/VenueHeader'
import { NRIScoreCard } from '@/components/venue/NRIScoreCard'
import { VenueMap } from '@/components/venue/VenueMap'
import { ReviewSection } from '@/components/venue/ReviewSection'
import { RelatedVenues } from '@/components/venue/RelatedVenues'
import { venueJsonLd } from '@/lib/schema/venue'
import { notFound } from 'next/navigation'

export const revalidate = 3600 // ISR: إعادة التحقق كل ساعة

export async function generateMetadata({ params }: Props) {
  const venue = await getVenueBySlug(params.slug)
  if (!venue) return {}

  const reviewCount = venue.venue_reviews?.length ?? 0
  const avgRating = reviewCount > 0
    ? (venue.venue_reviews.reduce((sum, r) => sum + r.rating, 0) / reviewCount).toFixed(1)
    : null

  return {
    title: `${venue.name} -- Specialty Coffee in ${venue.city} | NRI ${venue.nri_score}`,
    description: avgRating
      ? `${venue.name} in ${venue.city} scores ${venue.nri_score}/10 NRI. Rated ${avgRating}/5 from ${reviewCount} reviews. ${venue.description?.slice(0, 80)}...`
      : `${venue.name} in ${venue.city} scores ${venue.nri_score}/10 on our Neighbourhood Relevance Index. ${venue.description?.slice(0, 100)}...`,
    alternates: {
      canonical: `/venues/${params.country}/${params.city}/${params.slug}`
    }
  }
}

export default async function VenuePage({ params }: Props) {
  const venue = await getVenueBySlug(params.slug)
  if (!venue) notFound()

  const related = await getRelatedVenues(venue.id, venue.city, venue.nri_score)

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(venueJsonLd(venue)) }}
      />
      <article>
        <VenueHeader venue={venue} />
        <NRIScoreCard score={venue.nri_score} breakdown={venue.nri_breakdown} />
        <VenueMap lat={venue.lat} lng={venue.lng} />
        <section className="venue-body">
          <h2>About {venue.name}</h2>
          <p>{venue.description}</p>
          {venue.menu_highlights && (
            <>
              <h3>Menu Highlights</h3>
              <ul>
                {venue.menu_highlights.map(item => (
                  <li key={item}>{item}</li>
                ))}
              </ul>
            </>
          )}
        </section>
        <ReviewSection reviews={venue.venue_reviews} />
        <RelatedVenues venues={related} currentCity={venue.city} />
      </article>
    </>
  )
}

لاحظ revalidate = 3600. هذا هو ISR -- الصفحة يتم إنشاؤها بشكل ثابت في الطلب الأول ومخزنة مؤقتاً لمدة ساعة. زحف Google دائماً يحصل على HTML سريع. تتدفق البيانات الطازجة في دورة إعادة التحقق التالية. هذا يهم كثيراً بميزانية الزحف.

ما انكسر وكيف أصلحناه

هنا حيث تصبح معظم الدراسات غير صادقة. تعرض النتائج دون أشهر من تصحيح الأخطاء. كان لدينا ثلاث مشاكل رئيسية.

المشكلة 1: Deluxe Astrology -- Crawl Budget جوع

أطلقنا 91,000 صفحة وبنية خريطة موقع مسطحة. فهرس Google حوالي 12,000 صفحة في الشهر الأول وبعدها... توقف. أظهر تقرير تغطية GSC "اكتشاف - غير مفهرس حالياً" لعشرات الآلاف من عناوين URL.

كانت المشكلة ثنائية. أولاً، كانت خريطة الموقع لدينا ملف واحد بـ 91,000 عنوان URL. توصي Google بـ 50,000 كحد أقصى لكل خريطة موقع، لكن حتى ضمن هذا الحد، لا تشير خريطة موقع ضخمة واحدة إلى الأولوية. ثانياً، كان الربط الداخلي ضعيفاً -- كانت العديد من الصفحات قابلة للوصول فقط من خلال خريطة الموقع، وليس من خلال روابط على الصفحة.

الإصلاح:

  1. إعادة هيكلة خريطة الموقع: كسرنا خريطة الموقع الأحادي إلى خرائط موقع قائمة على الفئات. sitemap-celebrities.xml، sitemap-horoscopes-en.xml، sitemap-horoscopes-es.xml، إلخ. كل أقل من 10,000 عنوان URL.

  2. إصلاح الربط الداخلي: أضفنا روابط سياقية عبر كل صفحة. صفحات المشاهير الآن ترتبط بمشاهير ذوي صلة (نفس علامة البروج، نفس المهنة، نفس سنة الميلاد). صفحات الأبراج ترتبط بملفات تعريف المشاهير لتلك العلامة. كل صفحة تتصل بـ 8 صفحات على الأقل.

  3. إزالة الصفحات الرقيقة: قتلنا حوالي 4,000 صفحة مع أقل من 200 كلمة من المحتوى الفريد. كانت هذه أساساً صفحات مولدة تلقائياً لمجموعة لم تضيف قيمة. صفحات أقل، لكن جودة أعلى.

بعد هذه التغييرات، ارتفعت الفهرسة من 12K إلى 91K على مدار حوالي 10 أسابيع. كان الربط الداخلي هو أكبر ذراع.

المشكلة 2: HostList -- ISR التكوين الخاطئ

أطلقت HostList مع export const dynamic = 'force-dynamic' على كل صفحة. هذا يعني أن كل طلب واحد -- بما في ذلك كل زحف Googlebot -- ضرب Supabase في الوقت الفعلي. مع الزحف من Google لآلاف الصفحات يومياً، كانت مثيلة Supabase لدينا تتعرض للضرب، وأوقات الاستجابة ارتفعت، وانتهت الحال ببعض الصفحات ققت انتهاء المهلة أثناء الزحف.

الإصلاح: انتقلنا إلى export const revalidate = 3600. يتم تخزين الصفحات مؤقتاً بشكل ثابت وتخدم في أقل من 100ms. Supabase فقط يحصل على تصحيح مرة واحدة لكل ساعة لكل صفحة بدلاً من مرة واحدة لكل طلب. انخفض وقت الاستجابة p95 من 2.8 ثانية إلى 47 ملي ثانية. بدأ Googlebot بالزحف 3x من الصفحات أكثر يومياً لأنها لم تكن تنتظر حول.

المشكلة 3: Not Another Sunday -- محتوى مكرر عبر الدول

بعض سلاسل المقاهي تعمل في دول متعددة. Starbucks Reserve في Tokyo و Starbucks Reserve في London في الأصل كان لها محتوى صفحة مشابه جداً لأن القالب شدد على معلومات العلامة التجارية على محتوى محدد للموقع.

الإصلاح: وزنا محتوى محدد للموقع أعلى بكثير. أوصاف الحي، مقارنات مقام قريبة، معنويات المراجعة المحلية، والتسعير المحدد للبلد الآن تجعل 70%+ من كل صفحة. معلومات العلامة التجارية قسم صغير. توقف Google عن وضع علم على هذه كبدلات قريبة.

النتائج: هوكي ستيك والإخفاقات الصادقة

تُظهر بيانات GSC المدمجة عبر جميع المشاريع الثلاثة منحنى هوكي ستيك الكلاسيكي -- مسطح لأسابيع، ثم النمو الأسي مع ثقة زحف Google في مجالاتنا.

المقياس الشهر 1 الشهر 3 الشهر 6 الشهر 12
إجمالي الصفحات المفهرسة 18,200 67,000 189,000 253,000
النقرات العضوية اليومية 340 2,100 8,400 19,600
المتوسط. الموضع (جميع الاستعلامات) 42 28 16 11
طلبات الزحف/يوم (جميع المواقع) 4,200 12,800 31,000 48,000
تكلفة Supabase الشهرية $75 $75 $125 $150
تكلفة Vercel الشهرية $40 $60 $60 $60

لكن دعني أكون صادقاً حول الإخفاقات أيضاً. حوالي 8% من صفحاتنا لا تزال تجلس في "Discovered -- currently not indexed" بعد 12 شهر. هذه تميل إلى أن تكون صفحات الذيل الطويل ذات جهد حركة منخفضة -- صفحات رقم ملاك محددة في لغات حجم بحث منخفضة، أو شركات استضافة في أسواق صغيرة. يمكننا ربما فرض فهرسة هذه مع المزيد من الروابط الداخلية، لكن العائد على الاستثمار ليس هناك.

كان لدينا أيضاً فترة حول الشهر الرابع حيث انخفضت حركة Deluxe Astrology 30% بعد تحديث Google الأساسي. تعافت على مدار 6 أسابيع دون أي تغييرات على جانبنا، لكن كانت هذه أسابيع مجهدة. تبدو المواقع البرمجية أكثر تقلباً خلال التحديثات الأساسية لأن Google إعادة تقييم إشارات الجودة عبر مجموعة الصفحة بأكملها في وقت واحد.

إذا كنت تفكر في بناء شيء بهذا الحجم، فقد قمنا بتفصيل نهجنا والتسعير في صفحة التسعير. بالنسبة لإنشاء موقع ثابت مستند إلى Astro -- الذي جربنا أيضاً لـ pSEO نقي ثابت -- تحقق من قدرات تطوير Astro.

SEO البرمجي مقابل المحتوى التقليدي: متى تستخدم أياً منهما

SEO البرمجي ليس بديلاً للمحتوى التحريري. إنها أداة مختلفة لوظيفة مختلفة.

العامل SEO البرمجي المحتوى التقليدي
الأفضل للـ استعلامات مدفوعة بالبيانات ("أفضل مقاهي في Shibuya"، "أبراج Leo اليوم") استعلامات مدفوعة بالقصد ("كيفية بقهوة صب")
فرادة المحتوى تأتي من بيانات فريدة لكل صفحة تأتي من منظور فريد / بحث
سرعة التحجيم 1,000+ صفحة في الأسبوع 2-5 مقالات في الأسبوع
عبء الصيانة تحديثات قاعدة البيانات، إصلاحات القالب تحديث محتوى دوري
بناء ثقة Google أبطأ (يحتاج إلى إثبات الجودة على النطاق) أسرع (يتم الحكم على كل جزء بشكل فردي)
ملف تعريف المخاطر أعلى (عقوبات محتوى رقيقة تؤثر على الموقع كله) أقل (مقالة سيئة واحدة لا تطرح النطاق)

النقطة الحلوة تجمع كليهما. Not Another Sunday لديها 137K صفحة مقام برمجية و 200+ دليل تحريري حول ثقافة القهوة وطرق التخمير ومسارات اكتشاف المقام محددة حسب المدينة. يبني المحتوى التحريري إشارات E-E-A-T التي ترفع النطاق بأكمله، مما يساعد الصفحات البرمجية على الفهرسة بشكل أسرع.

الأسئلة الشائعة

كم عدد الصفحات التي يمكنك بشكل واقعي الحصول على مفهرسة مع SEO البرمجي؟ يعتمد بالكامل على سلطة المجال وجودة المحتوى. على المجالات المقيمة مع ملفات تعريف الارتباط القوية، رأينا معدلات فهرسة 90%+ لـ 100K+ صفحات. المجالات الجديدة تناضل -- دراسة الحالة dev.to لـ 287K صفحة على مجال طازج تحصل على قرب صفر فهرسة هي المعيار، وليس الاستثناء. ابدأ بـ 1,000-5,000 صفحة عالية الجودة، بناء السلطة، ثم قياس.

ما هو الحد الأدنى من المحتوى لكل صفحة لتجنب عقوبات محتوى رقيقة؟ نهدف إلى 400 كلمة على الأقل من المحتوى الفريد لكل صفحة، بالإضافة إلى البيانات المنظمة والصور والروابط الداخلية. لكن عدد الكلمات وحده ليس المقياس -- يتعلق بـ ما إذا كانت الصفحة تجيب على استعلام المستخدم بشكل أفضل مما هو موجود. صفحة 200 كلمة مع جداول بيانات فريدة وخريطة يمكن أن تتفوق على صفحة 2,000 كلمة من نص عام.

هل SEO البرمجي آمن لا يزال بعد تحديثات المحتوى المفيد 2025 لـ Google؟ نعم، لكن فقط إذا كنت تنشئ صفحات مفيدة حقاً. تستهدف تحديثات 2025 من Google بشكل محدد محتوى برمجي منخفض الجودة موجود فقط لالتقاط حركة البحث دون توفير قيمة. المواقع مثل Zapier (70K صفحة، 140 مليون دولار ARR) تستمر في الازدهار لأن صفحاتها تحل مشاكل حقيقية. المواقع التي تتعرض للعقوبة هي التي تنتج تباينات من "Best {service} in {city}" بدون بيانات حقيقية خلفها.

كم تكلفة مكدس SEO البرمجي مع Supabase و Vercel؟ يعمل مكدس ثلاث مشاريع على حوالي $150-200/شهر. Supabase Pro هو $25/شهر لكل مشروع (نستخدم ثلاث مثيلات). Vercel Pro هو $20/مستخدم/شهر. كان إثراء AI عبر واجهة برمجية Claude هو تكلفة مرة واحدة تقريباً $180 لـ 28,840 سجل. بالنسبة لمعظم المشاريع تحت 50K صفحة، توقع $50-100/شهر في تكاليف البنية التحتية.

كم من الوقت يستغرق Google لفهرسة صفحات برمجية؟ توقع 2-4 أسابيع لزحف أولي لخرائط الموقع الخاصة بك، لكن الفهرسة الكاملة لمجموعات الصفحات الكبيرة تستغرق 3-6 أشهر. تظهر تجربتنا نمط هوكي ستيك: زحف بطيء لأول 6-8 أسابيع مع تقييم Google للجودة، ثم تسارع سريع بمجرد أن يقرر أن المحتوى الخاص بك يستحق الفهرسة. يؤثر الربط الداخلي وبنية خريطة الموقع بشكل كبير على هذا الجدول الزمني.

هل يجب أن أستخدم Next.js SSR أو ISR لصفحات SEO البرمجية؟ ISR، تقريباً دائماً. SSR (force-dynamic) يعني أن كل طلب زحف -- بما في ذلك كل زحف Googlebot -- يضرب قاعدة البيانات، مما ينشئ مشاكل في الأداء على النطاق ويهدر ميزانية الزحف على الاستجابات البطيئة. ISR مع revalidate = 3600 (أو حتى 86400 للتحديثات اليومية) يعطيك أداء موقع ثابت مع طازة البيانات الديناميكية. تعلمنا هذا بالطريقة الصعبة مع HostList -- الانتقال من force-dynamic إلى ISR انخفض وقت الاستجابة لدينا من 2.8 ثانية إلى 47 ملي ثانية.

كيف تتعامل مع الربط الداخلي عبر 100K+ صفحات؟ استعلامات محتوى ذات صلة مدفوعة بقاعدة البيانات. كل صفحة تشغل استعلام يجد 8-15 صفحات ذات صلة بناءً على علاقات البيانات الفعلية -- نفس الفئة، درجات مماثلة، قرب جغرافي، الخصائص المشتركة. لا تربط فقط عشوائياً للصفحات. يحتاج الربط إلى إحساس سياقي لكل من المستخدمين و Google. نستخدم دوال PostgreSQL في Supabase لحساب هذه العلاقات بكفاءة.

ما هي أكبر خطأ يرتكبه الناس مع SEO البرمجي؟ التركيز على عدد الصفحات بدلاً من جودة الصفحة. من المغري توليد كل مجموعة محتملة من بيانتك، لكن 10,000 صفحة ممتازة ستتفوق على 100,000 صفحة متوسطة في كل مرة. قتلنا 4,000 صفحة رقيقة على Deluxe Astrology ورأينا الفهرسة زيادة عبر الصفحات المتبقية. يفسر Google الصفحات الرقيقة كإشارة بأن موقعك كله قد يكون منخفض الجودة. إذا كنت مستعداً لبناء صفحات برمجية بالطريقة الصحيحة، اتصل بفريقنا -- لقد تعلمنا هذه الدروس حتى لا تضطر.