Building an SEO-friendly website: the complete checklist before launch

We see it again and again: a business invests in building an impressive website, and only after launch asks how to get it ranking on Google. Then it turns out that the structure isn't suited to SEO, the code is heavy and there's no clear hierarchy, and some of the fixes require a rebuild. This checklist is meant to prevent that: it brings together what you need to decide, build and check before the site goes live, in the order things happen in a real project.

It's meant for business owners planning a new site or replacing an existing one, and for anyone managing a business website project who wants to know what to require of the developers and what to check before approving the launch. If you're the developer, you'll find the code-level details in our technical checklist for developers (in Hebrew).

Why building and SEO are one decision

Separating the website build from its SEO is the most common source of trouble we run into. A site that was well designed but built without thinking about URL structure, speed and markup arrives at the SEO stage with a list of fixes, and some of them require a rebuild. Fixing after the fact almost always costs more than doing it right from the start, because it includes the work you already paid for, the redirects and testing, and the months when the site isn't moving up.

The reverse is also true: SEO that starts before it's clear what the site needs to sell brings traffic to pages that aren't built to convert it. That's why, in a well-run project, the developer and the SEO specialist work together from the scoping stage, and don't meet only at the end to "sort out the tags." The checklist below is built exactly that way: what you decide before development, what you build during development, what you check on launch day and what you measure afterward.

Stage 1: decisions made before the first line of code

Three decisions made before development determine how easy it will be to rank the site in the years ahead: which pages it will have, how they're organized, and what their URLs look like.

Keyword research before the page map

Before deciding which pages will be built, you need to know what customers search for and what type of page Google ranks for each search. Every page on the site should serve a single search intent: service pages target commercial keywords such as עורך דין פלילי בתל אביב ("criminal lawyer in Tel Aviv"), and articles target informational questions such as מה העונש על עבירת תנועה ("what is the penalty for a traffic violation"). Anyone who skips this stage builds the site structure on a guess, and discovers after launch that the pages don't answer what people actually type.

If you don't have an organized keyword list yet, one-time keyword research with us costs ₪250 + VAT. The report brings together the 15 keywords with the highest search volume in your field, your business's authority keyword and recommended actions, and it's a good basis for the page map. For more on the types of intent and how to identify them, read our guide to search intent (in Hebrew).

Page map: one page for each search intent

The simplest rule in the checklist is also the one broken most often: two pages that target the same intent compete with each other, and Google has trouble deciding which of them to show. In practice, the page map is a simple table: the page name, the main keyword, the type of intent, and which pages it links to. If two rows in the table target the same keyword, merge them before design starts, not after there are already two pages live.

Silo architecture

A messy site is hard to crawl and hard to understand. With the silo method, you group content by main topics and don't mix them: every service gets a parent page, under it its subpages, and alongside them the articles that answer that topic's questions. For example, at a law firm:

• The home page links to all the practice areas.
• Employment law is a parent page that links to the subpages "Wrongful termination" and "Overtime claims."
• Articles such as "How long do you have to sue over a dismissal" link back to the parent page and the relevant subpages.

Internal links stay mostly within the silo, so each topic builds its own authority. It's also important to keep a reasonable depth: every important page should be reachable in no more than three clicks from the home page.

Readable, stable URLs

The URL is part of what Google and the visitor see in the results. It should be readable (/services/employment-law/ and not /?p=123), short, and include the page's topic without stuffing in keywords. Just as important: set it before launch and don't change it afterward. Every URL change after launch requires a 301 redirect, and every such redirect is one more point that can break. Also decide on one rule for the trailing slash and for lowercase letters, and stick to it across the whole site.

Choosing a platform

The platform question matters less than it seems, because any platform can pass this checklist or fail it. The difference is in how much control you have and how much work it takes:

You'll find a detailed comparison of the options in our article on custom code vs WordPress.

Stage 2: the technical infrastructure built during development

A site can look great and still be invisible to Google. The following components should be part of the development requirements from day one, not a layer added at the end.

Ready-made HTML from the server

This is the point where more modern sites fail than anywhere else. If the content appears only after the browser runs JavaScript, you're betting that every crawler will run it. Google can render JavaScript, but its own guidelines recommend server-side rendering or prerendering, partly because not all bots run JavaScript. The crawlers of answer engines don't always run it either. The test is simple: open the page source (not the developer tools) and make sure the heading, the text and the links are there.

Speed is an architecture decision, not a late optimization

You can compress images and minify files at the end of the project, and it will improve the metrics a little. What really decides it is how much code the page needs to run to display itself, and that's a decision made at the start of development: a site built light stays light, and a site built heavy doesn't become light later. Google measures the loading experience through the Core Web Vitals, and the targets it defines as good are an LCP of up to 2.5 seconds, an INP of up to 200 milliseconds and a CLS of up to 0.1.

• Images: a modern format such as WebP or AVIF, dimensions set in advance so the page doesn't jump while it loads, and lazy loading for images below the fold. It's best if the system does this automatically, so whoever uploads content doesn't have to remember.
• Fonts: only a few weights, loaded in a way that doesn't block the text from displaying.
• Third-party scripts: analytics, pixels and chat widgets load after the content, not before it. Every marketing tool you add costs speed, so add only what's really in use.
• Animations: heavy animations that look good on a powerful computer tend to freeze on basic phones. Test them on a real device, not just in an emulator.

For a full explanation of each metric and how to improve it, see our guide to site speed and Core Web Vitals.

Mobile first, for real

Google crawls and ranks according to the mobile version of the site (mobile-first indexing). The practical meaning: every piece of content, heading and link that appears on desktop needs to appear on mobile too. Text hidden on mobile to "clean up" the design, or a menu that shows only some of the pages on mobile, hurts exactly the version Google reads.

Accessibility and semantic structure

One H1 heading per page, a logical H2 and H3 hierarchy, alt text for images, keyboard navigation and sufficient color contrast. All of these serve visitors with disabilities first, and in Israel they're also a legal requirement for most businesses that serve the public. They also help crawlers understand what's important on the page, because a screen reader and a search engine bot rely on the same structure. You'll find what the law requires and how to comply in our guide to website accessibility under Israeli law.

Security

HTTPS is a basic requirement: browsers mark a site without an SSL certificate as not secure, and visitors leave. Beyond that, a hacked site may get a warning in the browser and in the search results and lose traffic until the problem is dealt with. So check that the system and plugins are kept updated, that the admin interface is kept separate and protected, and that there's a backup you can restore from.

Automated checks before every update

On a site that's updated often, the safe way is to check automatically before every deployment that the canonical URLs are correct, that the sitemap is built properly and that the robots.txt file doesn't block important pages. A check like this is written once and catches problems that are usually discovered only after traffic has already dropped.

By the same principle, if you're considering generating pages in bulk from a database, for example a page for every city, make sure each page has unique and genuinely useful content. Pages that differ from each other only in the city name are considered doorway pages under Google's spam policies, and that's a risk, not a shortcut.

Stage 3: markup and content that search engines and answer engines understand

Schema for every page type

Structured data markup in JSON-LD format tells machines what each page is: who the business is (Organization or LocalBusiness), where the page sits in the site structure (BreadcrumbList), and what type of content it is (Article, Product or Service). That way Google and the answer engines get the information organized, instead of guessing it from the text. The important rule: the markup describes only what actually appears on the page. Marking up questions, reviews or prices the visitor doesn't see goes against Google's guidelines.

One canonical URL and handling thin pages

Every page should have one canonical URL, even when it can be reached in several ways: with parameters, with or without a trailing slash, or from a print version. At the same time, automatically generated pages with no real value, such as tag archives, date archives and internal search results, get noindex or aren't created at all. That way the crawler spends its time on the pages you want to rank, not on duplicate versions of them.

Planned internal links

An internal link is your way of telling Google which page is important. Link from the strong pages on the site, such as the home page and the service pages, to the pages you want to rank, and use anchor text that describes the linked page, not "click here." Every article links to the service page it supports, and every service page links to the articles that answer its questions. The difference between internal links and backlinks, and what each one contributes, is laid out in our guide to internal links and backlinks (in Hebrew).

Content written as an answer

Until recently, the goal was to appear in the list of links. Today a growing share of searches ends in an answer the engine writes itself, on Google and in tools such as ChatGPT, Gemini and Perplexity, and that answer is drawn from several sources. What gets pulled is content built as an answer: a question as a heading, a short, direct answer below it, and then the detail. So on every service page, plan a real FAQ block in advance, and state facts in short sentences that can be quoted, instead of marketing paragraphs that no claim can be extracted from.

Answer engines still have to decide whom to trust, and they rely on the same authority signals: who gets linked, who gets cited and who gets mentioned together with the topic. So you don't need a separate site for them. The same site serves both worlds, and what changes is the way it's written. More on that in our guide to SEO for AI engines.

Pages built to convert

Traffic that doesn't turn into an inquiry isn't worth much. On every service page, the visitor should understand within seconds what's being offered and what the next step is: a prominent button, a phone number you can tap on mobile, and a short form. A form with 15 fields drives away even serious customers, and three fields (name, phone and what you need) are enough to start a conversation.

Stage 4: launch day

Most serious problems happen on launch day itself, so go through this list before you announce the new site:

• Remove the crawl block from the development environment. This is the most common mistake: a noindex setting or a robots.txt block that was correct during the build stays on the live site, and the site stays invisible for weeks until someone notices.
• 301 redirects from every old URL. If the site replaces an existing one, every old URL that has traffic or links should redirect to the matching new URL, not to the home page. Google details the process in its guide to moving a site with URL changes.
• Search Console. Verify the site, submit the sitemap, and use the URL Inspection tool to check that Google sees the main pages the way the visitor sees them.
• Measurement. Analytics and conversion tracking (forms, taps on the phone number and on WhatsApp) are active from day one, so there's a baseline for comparison.
• An external check. Run an SEO audit on the live site to catch missing titles, broken pages and speed problems before Google finds them.

After launch: what to measure and when

In the first months there's no point in measuring rankings for the core keywords, because they barely move. What does show whether the direction is right: how many of the pages were crawled and indexed out of all the pages that exist, how many new keywords the site appears for at all, and the click-through rate from the results. When all three rise, rankings for the competitive keywords start to move, at a pace that depends on the field, the competitors and the authority the site builds up.

That authority isn't built in code. It's built from content that covers the topic in depth and from links from other sites. This is where a properly built site starts to pay back the investment: organic SEO on sound infrastructure starts from a better place, because you don't waste the first months on fixes. Our monthly packages combine work on the site itself with links from sites with DR/DA 50 to 90 authority, and start at ₪1,790 a month + VAT. You'll find all the packages on our SEO pricing page.

If you want to strengthen specific pages without a monthly package, you can start with buying backlinks: a single backlink costs ₪89 + VAT, and in large packs the price per link drops as low as ₪40 + VAT. Every link is published in an original article on a niche site built specifically for your field, with DR/DA 40 to 90 authority, as a dofollow link with a report for every link, and a free replacement if the link drops.

The condensed checklist

This is the short version of the list, to print or pass on to your developers. Every line is a yes-or-no check.

Before development

• There's a keyword list, and every planned page is assigned a main keyword and a single intent.
• No two pages target the same intent.
• The silo structure and the URL structure are final, including a uniform rule for trailing slashes and lowercase letters.
• Every important page is reachable in no more than three clicks from the home page.

During development

• The content, headings and links appear in the source code the server sends.
• LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1 in a mobile test.
• Images in a modern format with set dimensions, and external scripts load after the content.
• The mobile version contains all the content and links of the desktop version.
• One H1 on every page, a correct heading hierarchy, alt text for images and compliance with the accessibility requirements.
• HTTPS on every URL, a protected admin interface and an active backup.

Before going live

• Schema for every page type, describing only what appears on the page.
• A canonical URL for every page, and noindex for thin pages.
• A sitemap that updates automatically.
• Every service page links to its articles, and every article links to its service page.
• An FAQ block on the service pages, and a short form with a tappable phone number.

On launch day and after

• No noindex or robots.txt block left over from the development environment.
• 301 redirects from every old URL to the matching new URL.
• The site is verified in Search Console and the sitemap has been submitted.
• Analytics and conversion tracking are active.
• Monthly tracking: indexed pages, new keywords and click-through rate.

Frequently asked questions

Does every website need Schema markup?

Yes, at least at the basic level: the business's identity, the navigation structure and the page type. Additional markup such as product, article or FAQ fits according to the type of content, and it's what makes rich results on Google and more accurate retrieval by answer engines possible.

Is it better to build a new website or upgrade the existing one?

If the URL structure is logical, the site gets crawled and the problem is mainly design and speed, an upgrade is usually cheaper and safer. A new site with orderly 301 redirects pays off when the URL structure is broken, there's a lot of duplicate content, or the system limits you in a way you can't work around.

How many pages does a business website need?

At least one page for each service you want to appear for on Google, and a page for each main question customers ask. The number matters less than the principle: every page answers a single search intent, and no two pages target the same intent.

Does site speed really affect rankings?

Speed is one of the signals Google takes into account, but the bigger effect is indirect: visitors abandon a slow page before it loads, and on mobile that happens fast. A fast site improves both the chance of ranking and the conversion rate from the same traffic.

Do I need a separate website for AI search engines?

No. The same site serves Google and the answer engines, provided it serves ready-made HTML from the server, is marked up with Schema and is clearly written. What changes is the way the content is written: a question as a heading, a direct answer below it and facts that can be quoted.

How long does it take to build and rank a website from scratch?

The build itself usually takes a few weeks, depending on the scope. SEO is an ongoing process: the first signs in search appear months after launch, and movement on competitive keywords takes longer. There's no fixed timeline, because the pace depends on the field, the competition and the authority the site builds up.

Should you wait until the site is perfect before starting SEO?

No. It's enough for the infrastructure to be sound, meaning the site gets crawled, is fast and is clear. Design and content improvements can continue alongside SEO, and that's even better, because the search data shows which pages are worth improving first.

What costs more over time, building the website or SEO?

The build is a one-time expense and SEO is a monthly expense, so over a year or two SEO is usually the bigger one. The right comparison is between the total cost and the inquiries the site generates, and a properly built site makes SEO cheaper because there's no need to pay for fixes.

What to do next

If you're about to build a website, pass the condensed checklist on to your developers and ask for an answer on every line before you start. If the site is already live, run a free SEO audit on it and go through the list against the results. And if you want a site built to this list from day one, all the details about our business websites are on the service page, and you can also talk to us or call 050-741-8449.