там ще такий прикол, що в хромі

{}+{}

сприймається як два літерали, а в firefox вже нормально, перше - блок, а друге -літерал, і від того різні результати виходять

Не дуже добре з SEO.
У нього трохи інша задача. Динамічні дешборди, приватні розділи і все таке.
Інколи метатегів можна навішати на сторінці і цього буде достатнь. (title, description)

А взагалі - для простих сайтів із відносно статичним контентом, який повинен індексуватися (блоги, статі і т.д.) - або старі добрі способи із рендерингом зразу на бекенді (handlebarsjs, Nunjucks і т.д., купа їх, бекенд зразу рендерить html і віддає на клієнт), або ж server-side rendering для фронтенду
Добавите собі ще один пункт до вчорашнього списку, десь перед тестами)

Якщо коротко, то варіант.
1) Що ви хочете індексувати? Щоб по запиту "Ваше Ім'я Резюме" знайшли цю візитку? Метатеги достатньо добавити.
2) Весь контент? Добре, використайте server-side rendering.

P.S. Ви ж це будете рекрутеру все одно в приватних повідомленнях давати, точно треба індексувати гуглу це?

за багато років роботи з js так і не запам'ятав оці "приколи"

а на друге запитання я маю дві відповіді:
1 -- мови програмування бувають зі статичною (C/C++, Java, Haskell)
та динамічною типізацією (JS, Python, Erlang)

типізація буває слабкою(небезпечною) (C/C++, JS)
чи строгою(сильною, безпечною) (Python, Erlang, Haskell)

у випадку зі строгою статичною типізацією (Haskell)
компілятор не дасть вам скомпілювати функцію,
у якій ви до 2х собак додаєте 7 блох з собаки,
та значення цієї функції підставляється там,
де очікується N апельсинів

компілятор скаже
"Василю, ти тверезий?
блохи (рядок в сумі з собаками (рядок 9)
не дають апельсинів (очікуваних в рядку 13),
я не можу скомпілювати цей код, виправлЄй!"

у випадку зі строгою динамічною типізацією (Erlang)
ми отримаємо помилку(виключення) в рантаймі

> 1 + "1".
** exception error: an error occurred when evaluating an arithmetic expression
     in operator  +/2
        called as 1 + "1"

у випадку зі слабкою(небезпечною) типізацією ми отримуємо:

-- падіння космічних апаратів (не пригадую, як називався, лише причину --
сішний float неявно приводився до int)
тобто, небажані результати

-- неочікувані "отут треба пофіксити, бо я неуважно написав, не перевірив etc"

-- різні "wft code" == що це таке, як приводиться-інтерпретується,
що воно повертає, і взагалі, як воно працює...

imho, з сильною типізацією жити легше,
зі слабкою -- важче

це була 1а відповідь))

2 -- js -- це не добряче продумана та файно спроектована мова програмування (Erlang, Haskell etc),
це "так історично склалось",
це щось з чимось,, недорозуміння, яким малювали сніжинки в браузерах в нульових,
і яке зараз називають топ мовою лише через відсутність альтернатив - інших мов в браузері

тут старі баги називають фічами,
їх не виправляють, а докидують нових ))

-- і ми маємо все важчі веб-сторінки,
все товстіші і прожорливіші браузери...

В мене давно крутиться в голові версія fuelphp + reactjs. Різні адмінки і мембер зони - чистий реакт, а рестфул на fuel і для паблік контенту зробити так, щоб за адресою яка резолвиться (slug для якого існує в базі сторінка), fuel генерував відповідь з найтупішим шаблоном, де весь контент був розміщений у <noscript>, а нижче підключався б знову ж таки реакт для живих юзерів.

Але я ніяк не почну це реалізовувати, бо трохи рукожоп, торохи ледар і взагалі на власні пет-проекти дуже мало часу маю. Але собі я бачу саме такий стек: fuelphp + reactjs + ant.design. Щодо redux я наче й зрозумів, що воно таке, але, доки не поюзав, ніяк не зрозумію, навіщо воно потрібне.

А мене якраз це й привабило в JS - краса потворності.

Навіть назва - якесь недолуге непорозуміння. Ммм... кайф.

Навіть гірше. Початкова ідея була (і лишається) в тому, щоб, задля безпеки, не передавати активного вмісту - лише HTML/CSS. Активним у клієнта має бути лише браузер. Звісно, травмований код потребував JS. JS - це костиль HTML для того, щоб робити те, що забули додати в браузер, і з міркувань безпеки JS також скалічений. Але через перегони браузерів стосовно швидшого каліки JS став швидким, і в декого виникла ідея писати на них щось серйозне - типу другого браузера в браузері (React, Angular) або серверного коду (Node). Ну, тобто якщо скаліченість HTML вас обмежує, то React є костилем.
Таким чином рендерінг на сервері - це костиль до костиля, зібраного зі штучно пришвидшених костилів для навмисно скаліченого коду. Живіть тепер із цим.

якщо ці інваліди декілька секунд гальмують
з доставкою контенту для пошукового павука --
все зрозуміло

гугл розпочав понижати в видачі сайти, які довго завантажуються

я не працював з реактом та ангуляром,
працюю з vanilla.js та вебсокетами фреймворку n2o (Erlang),
Google PageSpeed Insights дає оцінку 100 зі 100

для порівняння --
типічному вордпресу Google PageSpeed Insights дає оцінку ~ 34 зі 100

з іншої сторони -- гугл вперто не хоче індексувати деякі сторінки,
де вебсокету взагалі немає, де немає динамічного підзавантаження контенту
imho проблема точно не у вебсокетах, не в js

В мого вордпресу майже соточка на десктоп-версії.

Щоправда мобільна версія має менше, ніж половину того. Але то вже інша історія.