SEO Is Not Enough Anymore: What the LLM Era Demands from Your Frontend

A few months ago, we started noticing something frustrating.

Our frontend looked good. The product was solid. Pages were indexed. Metadata existed. But organic visibility was inconsistent, and crawler behavior was unreliable.

The platform was originally built with ReactJS as a client-side app.

For users, everything worked.

For crawlers, not really.

Some pages loaded as nearly empty HTML shells before hydration. Important content only appeared after JavaScript executed. Structured data was inconsistent. Arabic and English pages sometimes confused crawlers.

Google could eventually figure some of it out.

LLM crawlers struggled much more.

That was the turning point.

We stopped thinking only about SEO and started thinking about machine readability.

So we migrated the frontend to Next.js 16 using the App Router and rebuilt the platform around server rendering.

At first, the goal was simple:

• better indexing
• faster rendering
• cleaner metadata
• proper multilingual support

But during the migration, we realized the real challenge wasn’t Google anymore.

It was AI crawlers.

The Old SEO Checklist Wasn’t Enough

Initially, we felt confident about the migration.

We had:

• generateMetadata on routes
• canonical URLs
• OpenGraph tags
• Twitter cards
• XML sitemaps
• hreflang support for Arabic and English
• server-rendered page shells

A few years ago, that would’ve been considered a strong SEO setup.

But when we started auditing the platform for LLM crawler readiness, an entirely different checklist appeared.

And honestly, most React frontends are not prepared for it.

The First Big Problem: Crawlers Don’t Behave Like Browsers

One of the biggest lessons from the migration was simple:

Just because users can see content doesn’t mean crawlers can.

In React SPA architectures, it’s very easy to accidentally ship empty HTML.

We found patterns like this during the audit:

const Page = dynamic(() => import('./Page'), {
  ssr: false,
})

For the browser, that’s fine.

For AI crawlers, it’s dangerous.

Many crawlers don’t fully execute JavaScript.

So instead of seeing:

• products
• articles
• supplier data
• page structure

They only see a hydration container.

That completely changes how you architect a frontend.

After migrating to Next.js, we kept all important page content server-rendered and isolated client-side rendering only to interactive sections.

Something closer to this:

export default async function ProductPage() {
  const product = await getProduct()
  
  return (
      <>
        <ProductSchema data={product} />
        <ProductContent data={product} />
        <InteractiveGallery data={product} />
      </>
    )
}

That one shift made crawler-visible HTML dramatically better.

Then Came the LLM-Specific Layer

This is where the migration started feeling less like SEO work and more like infrastructure work.

Traditional SEO mainly optimizes for ranking.

LLM systems optimize for understanding.

They’re trying to answer questions like:

• What company is this?
• Is this source trustworthy?
• What type of content is this?
• Which language version should be referenced?
• Can this content be summarized confidently?

That requires more explicit structure from the frontend.

During the audit, we grouped the work into three layers.

1. Discoverability

The first layer was making the platform discoverable to AI crawlers.

We added an llms.txt file describing:

• what the platform does
• supported languages
• important sections
• canonical domain references
• sitemap references

We also updated robots.txt with explicit rules for AI crawlers instead of relying only on:

User-agent: *

The final setup included named user-agents like:

• GPTBot
• ChatGPT-User
• ClaudeBot
• PerplexityBot
• Google-Extended
• CCBot
• cohere-ai
• Bytespider

This matters because AI systems increasingly have different crawling and retrieval behavior than traditional search engines.

2. Identity and Structured Understanding

The second layer was structured identity.

Not just metadata for search engines, but machine-readable context for language models.

We implemented server-rendered JSON-LD across the platform using schema types such as:

• Organization
• WebSite
• Product
• ItemList
• Article
• FAQPage
• CollectionPage

The Organization schema became especially important.

We included:

• knowsAbout
• areaServed
• sameAs
• contactPoint

This gives AI systems a clearer understanding of:

• what the company does
• which industry it belongs to
• which region it serves
• whether the source is authoritative

We also implemented SearchAction under the WebSite schema.

This helps crawlers and AI systems understand how site-level search works and how content can be queried internally.

Example:

{
  "@type": "SearchAction",
  "target": "https://example.com/search?q={search_term_string}"
}

The important part is that these schemas were rendered server-side and embedded directly in the HTML.

Not injected after hydration.

3. Language and Regional Clarity

The platform was Arabic-first, which added another layer of complexity.

We had to make multilingual intent explicit across the frontend.

That included:

• hreflang support
• lang="ar"
• dir="rtl"
• inLanguage in JSON-LD
• aligned canonical URLs between language variants

Example:

<html lang="ar" dir="rtl">

And:

{
  "@type": "Article",
  "inLanguage": "ar-SA"
}

Without this level of clarity, AI systems can:

• reference the wrong language version
• summarize English content for Arabic prompts
• confuse regional variants
• misclassify translated pages

This becomes especially important for Arabic-first products because many global AI systems still default toward English assumptions.

The Small Details That Matter More Now

One surprising thing during the audit was how many silent problems existed.

For example, our SearchAction schema pointed to /search.

The route didn’t exist.

Humans would never notice.

But for crawlers, that’s a trust issue.

We also found:

• inconsistent domains between sitemap and metadata
• pages missing schema types
• metadata rendered client-side
• routes with weak server-rendered content

Traditional SEO tools don’t always catch these problems clearly.

LLM systems expose them fast.

The Unexpected Result

After the migration and cleanup work, we started monitoring traffic patterns closely.

What surprised us most wasn’t Google.

It was referral traffic from AI systems.

Based on GA tracking, some of the fastest-growing discovery sources became:

• ChatGPT
• Gemini
• Perplexity

Not because we gamed anything.

Simply because the frontend became easier for machines to understand.

That’s the part many teams still miss.

The frontend is no longer just a UI layer.

It’s becoming a machine-readable interface.

And in practice, that means:

• server-rendered content matters again
• structured data matters more
• multilingual clarity matters more
• crawler accessibility matters more
• semantic consistency matters more

SEO is still important.

But ranking is no longer the only outcome that matters.

Now the question is:

Can machines understand your platform well enough to trust, summarize, and recommend it?

Because increasingly, that’s where discovery starts.

You write TypeScript with Prisma, but your code is full of as unknown casts and custom types like UserDTO, MaybeUser, etc. You maintain duplicate type definitions that don’t match your DB. Type errors pop up randomly. Your team is confused. Sound familiar?

You’re not alone. Let’s fix this.

Why Custom Types Fail

Many teams create custom types that mirror Prisma models to feel in control — until it backfires:

• Drift: Your types no longer match the database.
• Casts everywhere: as unknown Hides real bugs.
• Extra work: Every schema change breaks your custom types.
• IntelliSense fails: You lose all TypeScript benefits.

Example mess:

type PublicUser = {
  id: number;
  email: string;
  posts: PostSummary[];
};

return user as unknown as PublicUser;

You’re forcing types, not matching them.

The Better Way: Prisma‑First Types

1. Use Prisma.XxxGetPayload<>

Let Prisma tell TypeScript exactly what shape your data has:

type UserWithPosts = Prisma.UserGetPayload<{
  include: { posts: true }
}>;

2. Omit or pick, don’t recreate

Want a public version?

type PublicUser = Omit<UserWithPosts, 'password'>;

3. Centralized selects

Define reusable selects:

export const publicUserSelect = {
  id: true,
  email: true,
  posts: { select: { id: true, title: true } }
} satisfies Prisma.UserSelect;

type PublicUser = Prisma.UserGetPayload<{ 
   select: typeof publicUserSelect 
}>;

Use this everywhere — handlers, services, validation schemas.

Easy Refactor Steps

1. Find your custom types that mirror Prisma models.
2. Identify common query patterns and relations.
3. Extract shared select/include objects.
4. Switch to GetPayload<> types.
5. Replace as unknown as with real typed queries.
6. Align your validation schemas (e.g. Zod) with new types.

Before vs After

Before:

user as unknown as PublicUser;

After:

const publicUserSelect = { … };

type PublicUser = Prisma.UserGetPayload<{ 
select: typeof publicUserSelect }
>;

const user = await prisma.user.findUnique({
  where: { id },
  select: publicUserSelect
});
return user;

✅ No casting. ✅ Real type safety.

Benefits You’ll See

• 50–70% fewer type definitions
• No more as unknown hacks
• Types auto-sync when schema changes
• Better IntelliSense and error checking
• Easier onboarding — types guide devs naturally

In Summary

Prisma’s auto-generated types are your friend. Don’t fight them — build on top of them. Your code becomes cleaner, safer, and easier to maintain. TypeScript finally becomes helpful again.

If you’re building an admin dashboard with real-time data from multiple APIs, there’s a good chance you’re juggling several asynchronous calls at once. That’s where Promise.allSettled comes in. It’s a powerful tool that lets you run multiple operations in parallel—without breaking if one fails.

Let’s break down how it works, using a real example from your dashboard code.

What Is Promise.allSettled?

Promise.allSettled is a JavaScript method that takes an array of promises and waits for all of them to finish, no matter if they succeed or fail.

Unlike Promise.all, which throws an error if any promise fails, Promise.allSettled Let you inspect the outcome of each operation individually.

Here’s How You’re Using It

const [productsResponse, categoriesResponse] = await Promise.allSettled([
  AdminProductService.getProducts({ page: 1, page_size: 1 }),
  AdminCategoryService.getCategories(),
]);

This line fires off two API calls in parallel:

• One to fetch products
• One to fetch categories

No waiting around. No try/catch blocks. No crashing if one fails.

⚙️ Why This Is Smart

1. Parallel Execution

You’re loading data faster by running both APIs at the same time.

// Sequential — slower
const products = await AdminProductService.getProducts();
const categories = await AdminCategoryService.getCategories();

// Parallel — faster
const [productsResponse, categoriesResponse] = await Promise.allSettled([
  AdminProductService.getProducts(),
  AdminCategoryService.getCategories(),
]);

If each call takes 200ms, parallel execution saves you 200ms of waiting time. In a dashboard, that’s noticeable.

2. Never Rejects

Even if one of the promises fails, your code doesn’t crash. Promise.allSettled returns an array where each item tells you whether it fulfilled or rejected.

{
  status: 'fulfilled',
  value: { /* API response */ }
}

{
  status: 'rejected',
  reason: Error('Something went wrong')
}

You can now write logic to handle each result, fallback gracefully, and keep the UI running smoothly.

3. Safe Result Handling

In your code, you’re handling potential failures like this:

setStats({
  totalProducts:
    productsResponse.status === 'fulfilled'
      ? productsResponse.value.total_count || 0
      : 0,
  totalCategories:
    categoriesResponse.status === 'fulfilled'
      ? categoriesResponse.value.total_count || 0
      : 0,
});

This ensures your dashboard never breaks — even if one of the APIs fails. You just show a fallback value (0), and the rest of the data still loads.

🆚 Promise.all vs Promise.allSettled

Here’s what happens if you use Promise.all instead:

try {
  const [products, categories] = await Promise.all([
    AdminProductService.getProducts(), // ✅
    AdminCategoryService.getCategories(), // ❌
  ]);
} catch (error) {
  // Whole operation fails — even the successful data is lost
}

With Promise.allSettled, it looks like this:

const [productsResponse, categoriesResponse] = await Promise.allSettled([
  AdminProductService.getProducts(), // ✅
  AdminCategoryService.getCategories(), // ❌
]);

const productCount = productsResponse.status === 'fulfilled' 
  ? productsResponse.value.total_count 
  : 0;

You still get the good data and skip the broken stuff.

✅ Why This Matters in Real Dashboards

Imagine this scenario:

• Products API: ✅ Returns 50 products
• Categories API: ❌ Times out

With Promise.allSettled, your dashboard still shows:

“50 Products, 0 Categories”

That’s way better than an error message — or worse, a blank screen.

💡 Takeaways

Using Promise.allSettled in your admin dashboard helps you:

1. Avoid full crashes when one API fails
2. Load data faster by running calls in parallel
3. Handle partial failures without confusing your users
4. Build resilient, user-friendly UIs

It’s a small change in your async strategy, but it makes a big difference in user experience.

If you’re a software engineer who codes on macOS and deploys to Linux, you’ve probably hit this bug at least once:
Your app works perfectly on your machine, but the moment it hits the server, it crashes with a MODULE_NOT_FOUND or similar error.

Most of the time, the culprit is simple but sneaky: case-sensitive file imports.

⚠️ The Hidden Difference: File System Case Sensitivity

The root of this issue comes from a key difference in how macOS and Linux handle file names:

OS File System Case Sensitivity macOS Case-insensitive (by default) Linux Case-sensitive

In plain terms, this means:

• On macOS, Navbar.js, navbar.js, and NAVBAR.js are all treated as the same file.
• On Linux, those are three completely different files.

🧨 Real Example: It Works on Mac, Fails on Linux

Let’s say you have a component saved as:

src/components/NavBar.js

But somewhere in your code, you import it like this:

import Navbar from './components/navbar.js';

macOS lets this slide. It finds the file despite the wrong casing.

Linux does not. It throws a file not found error and crashes your build or server.

😵 Why This Happens So Often

Because most engineers use macOS for local development, the OS silently corrects casing mistakes. Everything seems fine… until you deploy to a Linux server or run CI in a Linux container.

This disconnect can be frustrating — especially when bugs only surface in production.

🛡️ How to Avoid Case-Related Import Bugs

Here’s how to protect yourself and your team from falling into this trap:

✅ 1. Use a Linter That Flags Case Mismatches

ESLint with eslint-plugin-import can catch incorrect import casing during development.

Setup:

Install the plugin:

npm install eslint-plugin-import --save-dev

Update your .eslintrc.js:

module.exports = {
  plugins: ['import'],
  rules: {
    'import/no-unresolved': 'error',
  },
  settings: {
    'import/resolver': {
      node: {
        extensions: ['.js', '.jsx', '.ts', '.tsx'],
      },
    },
  },
};

This will throw an error if an import path doesn’t match the actual file name — including case mismatches.

✅ 2. Use Webpack’s Case Sensitive Paths Plugin

If you’re using Webpack, add this plugin to enforce case accuracy at build time.

Setup:

Install the plugin:

npm install case-sensitive-paths-webpack-plugin --save-dev

Update your webpack.config.js:

const CaseSensitivePathsPlugin = require('case-sensitive-paths-webpack-plugin');

module.exports = {
  // other config...
  plugins: [new CaseSensitivePathsPlugin()],
};

Now, any mis-cased import will fail the build with a clear, actionable error.

✅ 3. Develop on a Case-Sensitive Volume on macOS

To simulate Linux’s case-sensitive behavior locally, create a case-sensitive disk image on macOS:

hdiutil create -size 10g -fs "Case-sensitive APFS" -volname DevVolume ~/Desktop/CaseSensitiveDev.dmg

Mount the image, move your project into it, and develop as if you were on Linux. This forces macOS to respect casing and catch mistakes early.

✅ 4. Make Your CI Linux-Based

Always run your continuous integration (CI) pipeline in a Linux environment. This ensures any case mismatch or filesystem-sensitive bug surfaces before hitting production.

Popular CI services like GitHub Actions, CircleCI, and GitLab CI all support Linux runners by default.

💡 Pro Tips

• Stick to a consistent naming convention (e.g., camelCase, PascalCase, or kebab-case) and enforce it across your codebase.
• Add file naming rules to your linter or commit hooks using tools like Husky and lint-staged.
• If you’re using TypeScript, enable forceConsistentCasingInFileNames in your tsconfig.json.

{
  "compilerOptions": {
    "forceConsistentCasingInFileNames": true
  }
}

Final Word

“Works on my machine” isn’t good enough when your machine hides bugs.
Case-sensitive file imports are an easy mistake, and one of the most common causes of failed Linux deployments from macOS.

Don’t leave it to chance. Lint it. Build it. Test it like it’s already in production.

in this article, we are setting up an SSH connection instead of a direct GitHub repo URL.
So, here’s the steps below to resolve the issue:
open your terminal and run:

ssh-keygen -R github.com

This command is for updating known_hosts that saved in .ssh folder.

read more about github.com hosts

after updating hosts, we are ready to create our SSH key for GitHub authentication,

run the following command to generate public/private keys

ssh-keygen -o -t rsa -C “<your-email-in-github-account>”

after running the command, you will notice passphrase prompts in the terminal.

you can either click enter as the default value will be chosen which means no password or write your password.

the terminal will display public/private file locations.

Good job, remain two steps,

1- copy the public key by running this command

cat <your-public-key-location>

** public key with extension .pub

** public key location: `/Users/<username>/.ssh/id_rsa.pub`

2- copy the printed text and open your GitHub account to create a new SSH key, you can click here to github settings directly

add whatever name and paste the copied string.

now go back to the terminal with the project path and run the install dependencies command, will go with a flutter command

flutter pub get

Now, the private repos deps should start installing smoothly.

I picked JavaScript and Node.js to start with because they’re everywhere on the web. JavaScript lets you make websites interactive, and Node.js helps with server stuff, making sure everything runs smoothly on the back end.

Learning to code has its ups and downs. At first, it’s like learning a new language, trying to make sense of all these new words and rules. But the more you practice, the better you get. And building your own projects? That’s the best part. It’s where you get to put everything you’ve learned into action, make cool things, and see your ideas come to life.

One thing I didn’t expect was how awesome the coding community is. There are so many people out there ready to help, share their knowledge, and cheer you on. It makes the journey a lot less lonely and a lot more fun.

Looking ahead, I know there’s always going to be something new to learn, and that’s exciting. It means there’s always a way to get better, to create more amazing things, and to keep having fun with coding.

If you’re thinking about starting this journey, or if you’re already on your way, just keep going. Yes, it might be tough sometimes, but the feeling of solving a problem or finishing a project is unbeatable. Plus, you’re not alone. There’s a whole community here to support you.

So, let’s keep learning and coding together. Who knows what awesome things we’ll create?

Transitioning into the role of an engineering manager can be a thrilling experience, filled with the promise of new responsibilities, leadership opportunities, and the chance to shape a dynamic team. However, this transition is not without its share of challenges. In this article, we’ll explore the journey of starting as an engineering manager and discuss the human aspect of these challenges, offering insight into how to navigate them with grace and wisdom.

1. The Transition Period:

One of the initial challenges an engineering manager faces is the transition from a technical expert to a leader. It’s like learning to play a completely new instrument while still being expected to perform a solo. This transformation requires a shift in mindset, from solving technical problems yourself to enabling your team to tackle them.

Embrace the learning curve, as it’s perfectly normal to feel overwhelmed initially. Don’t be too hard on yourself, and take time to grow into your role. Lean on your mentor or senior colleagues for guidance as you navigate this change.

2. Balancing Technical and Managerial Duties:

As an engineering manager, you’ll walk a fine line between your technical responsibilities and your managerial duties. You must remain engaged with the technical aspects of your projects while also managing your team, setting goals, and ensuring efficient project delivery.

A key to success is finding the right balance. Stay hands-on with technical work to some extent, but also trust your team members to take the lead on certain technical aspects. Delegation is your ally here, and it’s a skill worth honing.

3. People Management Challenges:

Engineering management is not just about managing projects; it’s primarily about managing people. This can be one of the most rewarding yet daunting aspects of the role.

Your team will comprise individuals with unique personalities, strengths, and weaknesses. You’ll encounter conflicts, differing opinions, and the occasional challenge in keeping everyone motivated. The key here is communication. Create an environment where open and honest dialogue is encouraged, and address issues as they arise.

4. Time Management:

An engineering manager’s schedule can be hectic, with meetings, project planning, and mentoring sessions competing for your time. Effective time management is crucial to avoid burnout.

Prioritize tasks, delegate when possible, and set boundaries. Remember that you can’t do everything yourself, and sometimes saying ‘no’ or ‘not now’ is the best decision for your well-being and your team’s success.

5. Staying Connected:

As you transition into a managerial role, don’t lose touch with the human side of your team. Stay connected with your team members on a personal level. Engage in one-on-one discussions, show empathy, and provide support when they need it. A little kindness can go a long way in fostering a strong and loyal team.

Conclusion:

Becoming an engineering manager is a rewarding journey, but it’s not without its challenges. Embrace the transition, strike a balance between technical and managerial duties, and remember that people management is the heart of your role. Effective time management and maintaining a personal connection with your team are equally important.

In your quest to overcome these challenges, keep in mind that you are not alone. Seek guidance from experienced mentors, learn from your experiences, and continue to grow as a compassionate and effective engineering manager. Embrace these challenges, and with time, you’ll find yourself leading a thriving and dynamic team with grace and wisdom.

قواعد البيانات كثيرة وباختلاف محركاتها وانواعها ودائما هي الركن الأساسي في الكثير من المشاريع التقنية وقوتها تعطي قوة للمشروع واستقراره.

ومع تطور قواعد البيانات لم تقتصر على عمليات (اضافة ، قراءة ، تحديث، حذف ).

يوجد الكثير من العمليات والوظائف functions التي تزودنا بها محركات قواعد البيانات وبالتالي تعطي اضافة مميزة للمطور ليستخدمها ويستفيد منها في مشروعه .

في هذه المقالة السريعة سوف نستعرض ابرز النقاط عن Trigger

من ابرز خصائصها انها تبدء بالتنفيذ عند حدوث Event محدد .

• before & After insert data
• before & After delete data
• before & After update data

عند عمل تريقر عند اي حدث من الاحداث السابقة . سوف ينفذ تلقائيا التريقر عند وقوع الحدث .

بدون اي تدخل منك او استدعاء خارجي.

الكثير من الفوائد للتريقر ومساهمتها في رفع سرعة اداء قاعدة البيانات خاصة بعد فترة من العمل ع المشروع وتخزين مئات الحقول .

هنا بعض الافكار لاستخدامها

• عمل function وجدولته أسبوعيا يقوم بنقل سجلات المتابعة وتفاصيلها الى جدول الارشيف لعدم احتياجه بعد مضي اسبوع .

إضافة بيانات الى جدول التنبيهات (After insert ) بعد اضافة تعليق في جدول التعليقات على مقالة محددة .

ملاحظة

في بعض الحالات لا ينصح باستخدام التيرقر ويجب قراءة documentation الخاص بقاعدة بياناتك المستخدمة مثل :

عدم استخدام التريقر مع المفاتيح ذات صلة بجدول آخر Foreign keys لانها تمنع التعديل والحذف في بعض الحالات .

وبالتالي لا يستطيع التريقر من اداء مهمته على اكمل وجه.

حبيت ابرز بعض النقاط عن ما تقدمه قواعد البيانات غير الأمور التقليدية .

من حذف وإضافة وتعديل .

نسبية صفات الانسان

غالبا ما نسمع عن شخص ما يتحدث عن الرأي والرأي الآخر وكيفية تقبله , ايضا نشاهد الكثير من الاشخاص لديهم صفات مشتركة وصفات خاصة وهذا ما يتميزون به عن غيرهم . عندما نحس بتعابير وكلام الشخص الذي نشاهده , فأكثر ما نردده من مقولات الا وهي ( هذا الانسان فيه من صفات فلان ) .. وغيرها من التعابير .

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

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

فمثلا شخص تغلب صفاته الخيرة صفاته السيئة ولكن لا نعتقد انه لا توجد فيه صفات سيئة (0%) .

ولكنه غلبها بصفات خيرة وكذلك عند الاشخاص الآخرين . فلو أخذنا مفهوم نسب الصفات عند كل شخص

فان هذا يسهل علينا فهم طبيعة الانسان وطبيعة تصرفاته سواء انت او الآخرين . فلا نستغرب صفة سيئة بشخص مشهود له بالخير والعكس عند الشخص السيء لمن يسوي شيء فيه خير .

لانها في ذلك الموقف ارتفعت النسبة وغلبت الاخريات .

فيا ابن آدم اعمل على رفع نسبة الصفة التي ترغب ان تتصف بها والتي تقودك الى ما تطمح اليه .