By Shehab Waleed, Founder, Cairo Studio 3 min read
Our site has eight service pages, one for each thing we do, and each one targets the broad version of its subject: branding, web development, e-commerce. When we decided to write landing pages for search, the risk was clear from the start. Write a page about building websites in Egypt and it competes with the web development page we already have.
Two pages on one site aimed at the same search split the signals between them. A search engine has to pick one, sometimes picks the wrong one, and sometimes switches between them. That is keyword cannibalisation, and it is easy to cause with good intentions.
Narrower, and different from each other
So every landing page had to be narrower than its service page and different from its sibling. We settled on two per service, sixteen in all, each one either a niche within the service or the service plus a place.
Each landing page links to its parent service, to its sibling and to one landing page from every other service. A reader can move sideways, and a crawler can see how the pages relate. You can see the pattern on our website speed optimisation page.
A page has to pass before it publishes
The pages live as JSON in our repository and reach the CMS through a script. The script refuses any page that fails our checks. In simplified form:
if (words(overview) < 400) problems.push('too short');
if (steps.length !== 5) problems.push('needs 5 steps');
if (faq.length < 5) problems.push('needs 5+ FAQs');
if (DASH.test(text)) problems.push('contains a dash');
for (const uid of projects) {
if (!known.has(uid)) problems.push('unknown project');
}The word count stops thin pages. The project check means every page shows real work from our portfolio. The dash rule is house style, and a script is the only reviewer that never gets tired of enforcing it.
Built so the answer loads first
Each landing page opens with its keyword heading, rendered on the server and kept still, with no entrance animation. That makes the heading the largest thing painted on a phone, and the pages scored between 92 and 95 on mobile Lighthouse when they launched.
The questions at the bottom of each page come from one FAQ section that also writes the FAQPage structured data. Each page has exactly one such block, generated from the visible questions, so what search engines read matches what visitors see.
What we do not know yet
The pages went live in October, and it is too early to say which ones work. Search takes months to settle, and we would rather report real numbers later than guess now. We built none of the sixteen to compete with a service page. Whether search engines read them the same way is what we are waiting to see.
