Sanayi ve Üretim Firması Web Sitesi: Teknik Katalog, Teklif Talebi, ERP ve SEO

Bir satın alma sorumlusu, üretim hattında kullanılan parçanın kodunu web sitenizde arıyor. Başka bir müşteri teknik çizimine göre fason üretim istiyor. Üçüncü ziyaretçi ise ürün değil; hangi malzemeleri, prosesleri ve ölçüm imkânlarını desteklediğinizi anlamaya çalışıyor. Ana sayfadaki fabrika videosu üçünün de ilgisini çekebilir. Fakat teknik bilgiyi bulamıyor, doğru dosyayı indiremiyor veya teklif talebini tamamlayamıyorlarsa satış ekibiniz için iş üretmez.

Sanayi ve üretim firması web sitesi, katalog ile mühendislik ve ticari değerlendirme arasındaki sınırı doğru kurmalıdır. Bu rehber standart ürün üreten, siparişe göre imalat yapan veya endüstriyel çözüm geliştiren işletmelerin yöneticileri içindir. Örnek parça, sayılar ve mimari tasarımlar temsilidir; TankDev’in açıklanmamış bir üretim müşterisi, kapasite ölçümü veya satış başarısı olarak sunulmaz.

1. Aynı fabrika sitesi üç farklı satın alma görevini karşılar

RFQ, teklif talebidir; kesin fiyat, sipariş veya üretim sırası ayrılması anlamına gelmez. Seri ürün satan bir işletmede fiyat kuralı net olabilirken özel imalatta çizim, malzeme, yüzey işlemi, tolerans, miktar ve teslim koşulları birlikte değerlendirilir. İlk ekranda herkes için tek bir “satın al” veya “bize yazın” akışı kurmak bu ayrımı gizler.

Ana navigasyonu gerçek karar sorularına bağlayın: ürünler, üretim kabiliyetleri, kalite/dokümanlar, sektör uygulamaları ve teklif talebi. Örneğin “CNC işleme yapıyor musunuz?” sorusunun cevabı, yalnız bir makine fotoğrafı değildir. Hangi kapsamın doğrulanmış olduğu, nasıl teknik değerlendirme istendiği ve kamuya açık olmayan ayrıntının kiminle görüşüleceği anlaşılmalıdır.

2. Üretim kabiliyeti, kapasite ve kalite kanıtı aynı şey değildir

Kabiliyet, belirli bir işi yapabildiğinizi; kapasite ise belirli koşullarda ve zamanda ayırabileceğiniz üretim imkânını anlatır. Makine parkının listelenmesi, müşterinin istediği parçanın gelecek hafta üretilebileceğini kanıtlamaz. Tarihsiz bir aylık kapasite rakamını güncel teslim sözüne çevirmeyin. Mühendislik veya planlama ekibinin onayına bağlı alanları yayın akışında ayrı tutun.

ISO’nun ISO 9001 açıklaması, kalite yönetim sistemini ve bağımsız belgelendirme değerlendirmesini anlatır. Şirketin yönetim sistemi belgesini belirli bir parçanın her teknik gereksinimi karşıladığı iddiasıyla eşitlemeyin. Sertifika görselinin yanında kapsam ve güncellik bilgisi bulunmalı; müşteri veya denetim dosyaları paylaşım yetkisi olmadan yayınlanmamalıdır.

3. PDF kataloğundan yönetilebilir ürün veri modeline geçiş

ProductFamily(id, category_id, public_key)
ProductModel(id, family_id, manufacturer_part_number, lifecycle)
ProductRevision(id, product_model_id, revision_code, approval_state)
TechnicalAttribute(revision_id, property_key, numeric_value?, text_value?,
                   unit, method_or_condition?, source_document_id)
ProductTranslation(revision_id, locale, slug, approved_copy)
Document(id, revision_id, kind, content_hash, access_level, status)
Capability(id, process, verified_scope, reviewed_at, publication_approval)
PublicAvailability(product_id, source_version, observed_at, status)
Rfq(id, organization_scope, state, assigned_team)
RfqLine(id, rfq_id, revision_id?, requested_quantity, quantity_unit,
        approved_spec_snapshot, drawing_file_id?, drawing_hash?)
RfqRequest(organization_scope, idempotency_key, request_hash, rfq_id)
IntegrationDelivery(rfq_id, external_reference, state, attempt_count)
Outbox(event_id, aggregate_id, event_type, payload)

Internal SKU != manufacturer part number != customer/OEM reference != GTIN.
Public technical data != negotiated price != production schedule.
Specification revisions and translation approvals are explicit.

Model, revizyon ve tekil satış/üretim kaydını ayırın. Bir ürünün başlığı ve çevirisi değişebilir; kimliği entegrasyon için sabit kalmalıdır. Mühendislik revizyonu ise yalnız metin düzeltmesi değildir: eski çizime göre istenmiş teklif, yeni ölçülere sessizce dönüştürülemez. Kamuya açık teknik özellikler ile müşteriye özel fiyat veya üretim planı aynı API yanıtına konmamalıdır.

“50 mm” değerini her dilde ayrı serbest metin olarak tutmak arama ve filtrelemeyi kırılganlaştırır. Sayı, birim, özellik anahtarı ve gerekiyorsa ölçüm/uygulama koşulunu ayrı saklayın; ekranda yerelleştirin. Tolerans veya uyumluluk bilgisini yalnız nominal ölçüden üretmeyin. Eksik alanı sıfır gibi yorumlamak yerine bilinmiyor/onay bekliyor durumunu koruyun.

PIM veya onaylı ürün veri kaynağı pazarlama ve teknik yayın görünümünü, ERP ticari/operasyonel kayıtları, kalite sistemi ilgili onay ve belgeleri yönetebilir. Bunlar ürününüzde tek yazılımda da bulunabilir. Önemli olan yazılım etiketi değil, hangi verinin kim tarafından onaylandığının ve çelişki halinde hangi kaynağın doğru kabul edildiğinin yazılı olmasıdır.

4. Kodla arama, filtre ve uyumluluk kontrolünü ayırın

Sanayide müşteri çoğu zaman bir açıklamadan önce parça koduyla gelir. Üretici kodunu, iç SKU’yu, müşteri referansını ve eski kod eşlemesini ayrı alanlarda yönetin. Tire veya boşluk normalizasyonu yararlı olabilir; fakat iki farklı kodu aynılaştıracak kadar agresif olmamalıdır. GS1’in GTIN açıklaması bir ticari ürün tanımlayıcısını anlatır; GTIN ile şirketinizin iç kodu aynı alan değildir. Eksik tanımlayıcıyı uydurmayın.

• Önce tam üretici/parça kodu ve onaylı eski kod eşlemesiyle aday bulun.
• Malzeme, ölçü, seri ve uygulama alanı gibi yapılandırılmış filtreleri ayrı uygulayın.
• Yazım önerisini açıklayıcı gösterin; benzer kodlu parçayı sessizce kesin eşleşme yerine koymayın.
• OEM/muadil uyumluluğunu yalnız mühendislikçe doğrulanmış ilişki ve kapsam varsa sunun. Benzer metin veya vektör yakınlığı uyumluluk kanıtı değildir.

AI destekli arama, “şu uygulamada kullanılacak bağlantı elemanı arıyorum” gibi serbest soruyu ürün adaylarına yönlendirebilir. Ancak model ölçü, sertifika veya muadil uyumluluğu icat etmemeli. Açıklamasını dönen onaylı kayda dayandırmalı; veri yetmiyorsa teknik inceleme talebi açmalıdır. Genel arama mimarisini web uygulaması rehberinde açıklıyoruz; bu sektörde esas sınır, benzer parçanın yanlışlıkla uygun parça sayılmamasıdır.

5. RFQ: hangi çizim ve hangi şartlar için teklif istendi?

{
  "example_only": true,
  "intent": "request_for_quotation",
  "product_reference": "PLATE-50",
  "requested_revision": "B",
  "quantity": {
    "value": 500,
    "unit": "piece"
  },
  "specification_snapshot": {
    "width": {
      "value": 50,
      "unit": "mm"
    },
    "nominal_thickness": {
      "value": 6,
      "unit": "mm"
    },
    "material": "aluminium",
    "finishing": "requires_engineering_confirmation"
  },
  "drawing": {
    "private_file_id": "example-file-42",
    "sha256": "<verified-file-digest>",
    "review_status": "pending"
  },
  "requested_delivery": {
    "destination_country": "DE",
    "date": "<requested-date-not-a-promise>"
  },
  "result": "enquiry_received_not_a_binding_quote"
}

Bir RFQ satırını ürün bağlantısından ibaret tutmayın. Ürün/revizyon kimliği, talep edilen adet ve birim, onaylı özelliklerin o andaki özeti, yüklenen çizimin kimliği/özeti ve müşteri isteğinin sürümü kaydedilsin. Katalog yarın değişse bile dün hangi şartlarla değerlendirme istendiği görülebilmelidir. İstenen teslim tarihi ile işletmenizin kabul ettiği termin ayrı bilgiler olmalıdır.

Aşağıdaki örnek katalogdaki onaylı bir revizyona bağlı talebi gösterir. Yalnız müşteri çiziminden başlayan fason işte katalog ürün kimliği zorunlu değildir; dosyanın ve proses talebinin sürümü kaydedilir. Dosya taraması tamamlanmadıysa güvenli inceleme için bekletilir.

# Architectural pseudocode, not a completed ERP connector.
with db.transaction():
    previous = admit_request(scope, idempotency_key, request_hash)
    if previous:
        return same_receipt_or_409(previous, request_hash)
    revision = load_approved_public_revision(product_id, revision_id)
    require_quantity_and_unit_are_valid(quantity, quantity_unit)
    attachment = verify_private_upload_owner(file_id, requester_scope) if file_id else None
    if attachment:
        require_scan_is_accepted(attachment)
    rfq = create_rfq(
        immutable_spec_snapshot=revision.public_specification,
        quantity=quantity, unit=quantity_unit,
        drawing_hash=attachment.verified_hash if attachment else None,
    )
    bind_request_receipt(scope, idempotency_key, rfq.id)
    write_outbox("rfq.received.v1", {"rfq_id": rfq.id})
# Concurrent admission: unique(scope, idempotency_key).
# On conflict: rollback, load original request, compare payload hash.
# Engineering review and remote CRM/ERP calls happen outside this transaction.
return receipt(rfq.id, state="received")  # Not "priced" or "capacity booked".

# A later catalogue revision never silently rewrites an accepted RFQ.
# If the buyer changes the drawing, record a new RFQ revision and re-review.

Teklif isteğini alınca bir başvuru referansı verin. Mühendislik incelemesi, eksik bilgi talebi, ticari fiyatlama ve müşteriye teklif gönderimi ayrı durumlardır. Üretim planından veri almayan bir formun sonucu “kapasiteniz ayrıldı” olamaz. Teklif revize edildiğinde eski PDF ve e-postalarla hangi sürümün geçerli olduğu da kaydedilmelidir.

Aynı gönderimin tekrarını idempotency anahtarıyla ayırın; aynı firmanın farklı parça veya çizim için açtığı gerçek talepleri körlemesine birleştirmeyin. Transactional outbox, yerel kabul ile sonraki CRM/ERP teslimini bağlar. Uzak sistemde tek etki için sağlayıcının idempotency/dış referans sözleşmesi ve belirsiz sonuç mutabakatı gerekir. Detaylar entegrasyon rehberinde.

6. CAD ve teknik dosya yükleme: form ekinden daha fazlası

Müşteri çizimleri ticari açıdan hassas olabilir. Yüklemeyi web kökündeki herkese açık dosyaya çevirmeyin. Dosya, doğru organizasyon/talep kapsamına bağlanmalı; erişim her okumada denetlenmeli. Süreli indirme bağlantısı tek başına yetki modeli değildir: bağlantıyı kimin hangi kayıt için alabileceği ve dosyanın yayın/retention durumu belirlenmelidir.

OWASP dosya yükleme rehberi, izinli türler, boyut sınırları, dosya adı üretimi ve güvenli depolama gibi kontrolleri birlikte ele alır. Sadece uzantıya veya tarayıcının Content-Type alanına güvenmeyin. Karantina, kötü amaçlı dosya kontrolü ve gerekirse izole önizleme işçisi planlayın; yüklenen CAD/PDF’i uygulama sunucusunda sınırsız yetkiyle otomatik işlemeyin.

Çizim revizyonu değişince yeni dosya sürümü ve yeniden teknik inceleme ilişkisi kurun. Satış ekibinin e-posta ekiyle dolaştırdığı kopya ile portalın güncel dosyası çelişmesin. Kamuya açık katalog dokümanı, giriş gerektiren müşteri çizimi ve iç maliyet dosyası farklı yayın sınıflarıdır; hepsi aynı galeri bileşenine yüklenmemelidir.

7. ERP, stok ve termin: kamuya açık bilgi nerede durmalı?

Teknik katalog uzun süreli cache kullanabilir; stok ve özel fiyat aynı politikayla önbelleklenemez. Görüntülenen uygunluk bir okuma modeli olabilir, fakat sipariş kabulü yeniden yetkili kaynaktan doğrulanmalıdır. Son senkronizasyon, kaynak sürümü ve mutabakat sonucu izlenmeli; veri eskidiyse açık bir sorgulama/teyit akışı sunulmalıdır. Alıcılardan birinin sözleşmeli fiyatı başka alıcıya ortak cache üzerinden sızmamalıdır.

Sıfır stok daima üretilemiyor demek değildir; stok var daima istenen tarihte sevk edilebilir demek değildir. Parti büyüklüğü, malzeme tedariki, proses sırası ve kontrol ihtiyacı termin kararını etkileyebilir. Bu kararları bir pazarlama alanından hesaplamayın. Entegrasyon yoksa “teklif isteyin” demek, çalışmayan bir gerçek zamanlı stok/termin iddiasından daha doğrudur.

8. İhracat ve teknik SEO: katalog gerçekten bulunabilir mi?

Ürün kimliği ve teknik kaynak sürümü dil değişince değişmemeli; başlık, açıklama, dosya dili ve sunum yerelleştirilmelidir. Birim dönüştürülüyorsa kaynak değer, hassasiyet ve mühendislik onayı korunmalı. Müşterinin ürün kodunu çevirip farklı bir koda dönüştürmeyin. İngilizce URL altında Türkçe gövde yayınlamak, teknik alıcının ihtiyacını çözmez.

• Ürün/kabiliyet sayfaları okunabilir HTML, özgün title/açıklama, tek H1 ve ilgili teknik tablolara sahip olsun; önemli bilgi yalnız PDF içinde kalmasın.
• Her gerçek dil sürümü kendi canonical adresini kullansın; karşılıklı hreflang ve sitemap eşleşmesi doğru olsun.
• Ölçü, malzeme, seri ve sıralama filtrelerinin bütün kombinasyonlarını indekslenebilir sayfa yapmayın. Gerçek arama niyeti olan seçilmiş kategorileri yararlı içerikle yayınlayın.
• Eski ürün/çizim için durum ve sürümü açıklayın. Belgelenmiş halef ürüne bağlantı verilebilir; eşdeğerlik doğrulanmadan otomatik muadil yönlendirmesi yapmayın.

Filtreli gezinme rehberi, canonical yöntemleri ve dil sürümleri belgesi bu farklı konuları ele alır. Canonical, sınırsız filtre alanını tek başına çözen bir emir değildir. Özel bayi portalı ve teklif dokümanlarını arama indeksinden ayırmak ise erişim denetiminin yerine geçmez.

9. ProductModel ve teknik özellik şeması nasıl kullanılmalı?

ProductModel, üreticinin model/datasheet tanımı için bir sözlük türüdür. Modeli üretici Organization kaydına bağlayabilirsiniz. Özel bir schema alanı varsa onu kullanın; uygun alan bulunmayan özellikleri PropertyValue ile açıklayın. Aşağıdaki üretici ve parça kurgusaldır; teknik ölçüler örnek modelin görünür açıklamasıyla birlikte düşünülmelidir.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://factory.example/#manufacturer",
      "name": "Example Manufacturing",
      "url": "https://factory.example/en/"
    },
    {
      "@type": "ProductModel",
      "@id": "https://factory.example/#plate-50-rev-b",
      "name": "Example PLATE-50 specification, revision B",
      "url": "https://factory.example/en/products/plate-50",
      "mpn": "PLATE-50",
      "manufacturer": {
        "@id": "https://factory.example/#manufacturer"
      },
      "material": "Aluminium",
      "width": {
        "@type": "QuantitativeValue",
        "value": 50,
        "unitText": "mm"
      },
      "additionalProperty": [
        {
          "@type": "PropertyValue",
          "name": "Nominal thickness",
          "value": 6,
          "unitText": "mm"
        }
      ]
    }
  ]
}

Bu JSON makalenin çalışan yapılandırılmış verisine hayalî üretici/ürün olarak eklenmez. Örnekte fiyat ve GTIN yoktur; bilinmeyen veriyi tamamlamak için uydurulmamıştır. Gerçek sitede üretici kodu, malzeme, ölçü ve revizyon görünür içerikle aynı olmalıdır. Ürün sayfasının schema sözlüğüne uygun olması ile Google’da ürün zengin sonucu kazanması farklıdır.

Google ürün snippet belgesi, isimle birlikte offers/review/aggregateRating alanlarından uygun olanın gerekliliğini açıklar. Sadece teklif talebi alan bir ürün için sahte 0 TL fiyat veya uydurma değerlendirme eklemeyin. Gerçek teklif/yorum verisi yoksa belirli zengin sonuç uygunluğu sağlanmayabilir. Genel ilkeler de gösterim garantisi vermez.

10. Üretim firmam AI yanıtlarında nasıl doğru tanınır?

Bu bölümde görünürlüğü ele alınan işletme sizin üretim firmanızdır; TankDev bu altyapıyı geliştiren yazılım sağlayıcısıdır. Arama ve AI sistemlerinin okuyabileceği yararlı bilgi; hangi ürün/proses kapsamına sahip olduğunuz, kanıtı, teknik dokümanların güncelliği ve kiminle nasıl değerlendirme yapılacağıdır. Her sayfada “lider üretici” demek bu bilgilerin yerini tutmaz.

SEO; keşif, indekslemeye uygunluk ve arama niyetine cevap vermeyi kapsar. GEO çalışmaları üretken yanıtlardaki bilgi/kaynak temsilini inceler. Marka anılması, kaynak bağlantısı ve tedarikçi tavsiyesi ayrı gözlemlerdir. Google AI rehberi, kendi AI arama özellikleri için temel SEO’nun geçerli olduğunu ve özel dosya/schema zorunluluğu olmadığını belirtir; bunu tüm asistanlarda aynı seçimin yapılacağı şeklinde genellemeyin.

• Resmî şirket/üretici adı, alan adı, gerçek tesis ve iletişim bilgilerini tutarlı tutun.
• Kabiliyet, ürün ve kalite kapsamını onaylı bilgilerle anlatın; müşteri logosu veya belgeyi izin ve dayanak olmadan eklemeyin.
• Ürün kodu, revizyon, teknik tablo ve kaynak doküman arasındaki ilişkiyi açık tutun.
• Gerçek alıcı sorgularını izleyin: belirli proses/ürün/ülke kombinasyonunda hangi kaynak gösteriliyor? Platform, arama modu, tarih, dil ve cevap bağlamını kaydedin.

TankDev’in kendi sitesindeki SEO/GEO vakası teknik yaklaşımı belgeliyor; üretim sektöründe kazanılmış müşteri sonucu değildir. Temel indeksleme mekanizmaları için Google görünürlük rehberine bakabilirsiniz. Hiçbir site altyapısı üretim firmanızın belirli bir asistan tarafından önerilmesini garanti edemez.

11. Hazır katalog mu, özel web sistemi mi? Paketler nerede durur?

Hazır tema otomatik olarak yavaş veya güvensiz, özel kod otomatik olarak hızlı değildir. Büyük CAD/3B içerikleri ilk yüklemeye zorlamak yerine okunabilir teknik özet ve isteğe bağlı önizleme sunun. Core Web Vitals iyi eşikleri LCP ≤ 2,5 saniye, INP ≤ 200 ms ve CLS ≤ 0,1’dir; 75. yüzdelikte değerlendirilir. Laboratuvar puanını gerçek alıcı deneyimi veya teklif kazanma oranıyla eşitlemeyin.

8 Kasım 2026’da kontrol edilen TankDev web paketleri kapsamında Essential 50.000 TL, Advanced 150.000 TL başlangıç bedelidir. Sanayi firmanızın ürün/sayfa sayısı, dilleri, veri hazırlığı ve özel entegrasyonları teklifte netleşir.

Essential, ürün ve üretim kabiliyetini doğru anlatan yönetilebilir bir site için başlangıç olabilir. Advanced kimlik, dış profil ve AI görünürlük gözlemlerini ayrıca ele alır. İki paket de otomatik ERP, mühendislik hesap motoru veya ihracat müşterisi garantisi olarak sunulmaz. Paket özelliklerini karşılaştırın; hangi modülün gerçekten gerektiğine mevcut iş akışınızla karar verelim.

12. Başarıyı teklif kalitesi ve operasyonla birlikte ölçün

Tamamen varsayımsal aylık RFQ örneği:
120 kalıcı talep -> 45 nitelikli teknik/ticari talep
Kanal harcaması varsayımı: 90.000 TL
Talep başına kanal maliyeti: 90.000 / 120 = 750 TL
Nitelikli talep başına kanal maliyeti: 90.000 / 45 = 2.000 TL
Geliştirme, işletim ve mühendislik inceleme maliyeti bu hesapta yok.
Siparişe dönüşümü aynı talep kohortu olgunlaştığında ayrıca izleyin.

Nitelikli RFQ tanımını baştan yazın: ürün/proses uyumu, yeterli teknik bilgi, gerçek miktar/birim ve takip edilebilir iletişim gibi ölçütler kullanılabilir. Belge indirme ile teklif talebini; form tıklamasıyla kalıcı kaydı ayrı sayın. Özel imalatta uzun değerlendirme döngüsü varken bu ay alınan talepleri bu ay kapanan eski siparişlerle eşitlemeyin.

• Ürün kodu aramasında sıfır sonuç ve yanlış eşleşme; kullanılan filtreler ve doküman erişimi.
• Eksik teknik bilgiyle gelen RFQ oranı; ilk mühendislik dönüşüne ve ticari teklife kadar geçen süre.
• CRM/ERP teslim hataları, tekrarlar ve belirsiz sonuçta bekleyen talepler.
• Gizli dosyaya yetkisiz erişim denemeleri ve eski doküman revizyonuyla işlem riski.
• Olgunlaşmış talep grubunda teklif ve sipariş sonucu; ülke, ürün ve kaynak bazında ayrım.

13. Teklif öncesi hazırlık ve kabul kriterleri

TankDev ile görüşmeden önce örnek ürün verisi, güncel teknik doküman, proses kapsamı, mevcut ERP/PIM/CRM adları ve iki gerçek RFQ senaryosu hazırlayın. Sanayi web sitesi ihtiyacınızı paylaşın. İlk teslimde hangi verinin kamuya açık olacağı, kim tarafından onaylanacağı ve talebin kimde sonlanacağı netleşmelidir.

• Katalog: birim, revizyon, üretici/iç/OEM kodu ayrımı ve TR/EN teknik alan eşleşmesi doğrulandı mı?
• Talep: aynı gönderimin tekrarı, yeni çizim revizyonu, hatalı adet/birim ve başka müşterinin dosyasına referans sınandı mı?
• Entegrasyon: CRM/ERP cevabı kaybolunca kör yeniden işlem yerine sorgu/mutabakat var mı?
• Yayın: eski stok/termin verisi, kaldırılan belge ve onaysız çeviri doğru davranıyor mu?
• İşletim: dosya erişimi, yedek/geri yükleme, hesap/kaynak kod devri ve destek sorumlusu açık mı?

Kaynaklar ve örneklerin sınırı

Kaynaklar ve paket bilgisi 8 Kasım 2026’da kontrol edildi. Parça/üretici adları, RFQ verisi ve maliyetler kurgusaldır. Kodlar mimari açıklamadır; test edilmiş bir üretim/ERP uygulaması veya mühendislik uygunluk değerlendirmesi değildir.

• Schema.org: ProductModel
• Schema.org: PropertyValue
• Google: product snippets
• Google: structured data policies
• GS1: what is a GTIN?
• ISO: ISO 9001 explained
• OWASP: file upload
• AWS: transactional outbox
• Google: faceted navigation
• Google: localized page versions
• Google: canonical URLs
• Google: AI features
• Web Vitals