https://drive.google.com/drive/u/0/my-drive
The first problem is technical, not software-related.
My system was unable to access the content of the article itself, even after two attempts. The reason: the site menu is huge — hundreds of navigation links that appear at the beginning of the HTML code, pushing the content down so deeply that automated tools get cut off before reaching it.
This is a critical discovery in itself, not just my "mistake." Consider who else "encounters" your page in the same way:
Google bots
AI-based crawlers (e.g., GPTBot, ClaudeBot, PerplexityBot, GeminiBot)
Indexing systems using the RAG algorithm
When an AI model receives a page, it sees a huge pile of links before it gets to the content. Even if it doesn't get cut off, the weight of the content relative to the weight of the navigation is very low — and this is a negative signal. Modern models try to determine the "main content," but this is not always successful, especially on Hebrew WordPress sites.
This is one of the likely reasons why your site is probably indexed by AI models worse than it should be, even if the content itself is good.
What to do about it:
Ask the developer if it's possible to change the order of the HTML code so that the main content is placed before the menu (semantic HTML with <main> and <nav> in their places).
Add aria-label and role="navigation" attributes to the menu.
Add a "skip to content" link — you have it, but you need to ensure it works.
Consider creating a more "flat" menu instead of the current green one with more than 50 links.
Here is what you currently have — a real problem
The menu is displayed three times in the original HTML code:
One version for desktops
One version for tablets
One version for mobile devices
Each version contains more than 50 identical links. This means that the bot reading the page sees the same menu printed three times in the code, even if the user sees only one on any screen.
Options that do not require changing the navigation itself:
A. One menu with responsive CSS instead of three menus
Instead of Elementor printing three separate HTML versions and hiding/showing them with classes, you can print one menu that visually changes depending on the screen size using CSS. This reduces the HTML size by about three times without affecting the number of links or the navigation structure.
This requires developer work, as this is not a setting that can be changed from the Elementor interface — it requires modifying the template code or replacing the menu widget.
B. Lazy loading of the mobile menu
The mobile menu (hamburger) does not necessarily need to be fully printed in the original HTML. It can be dynamically loaded when the user clicks on the hamburger. This significantly reduces the HTML code without changing the navigation content.
C. Fixing the hidden H1
We've already talked about this — there is an H1 that is hidden on desktops and only displayed on tablets. Fixing just this is a task separate from reducing the menu size.
D. Removing unnecessary inline JavaScript from <head>
I looked at the code again — there is a lot of inline JavaScript in <head>, including whole scripts for the table of contents, internal AI scripts, and more. Most of this can be moved to a separate file or loaded at the end of the page. This does not change the navigation but reduces the amount of code that bots have to go through before reaching the content.
Risk assessment of these options:
A (one menu with CSS) — low-medium risk. A developer who understands what they are doing is required. The risk is that Elementor may not work well with the changes. After making changes, thorough testing on all devices is necessary.
B (lazy loading of the mobile menu) — low risk. If implemented correctly, the menu will still be accessible to bots through static links, it will just load later.
C (fixing H1) — minimal risk, we've already discussed this.
D (migrating JavaScript) — low risk, a standard optimization measure.
Important note: Before discussing options A and B, clarify with your developer whether this is even possible within the template you are using (Hello Elementor Child + PowerPack Elements). Some of the options proposed here may require relatively complex changes or replacement of the menu widget.
