Stevens / Ivan Issue Report

Контекст обсуждения (до PR #847) — переписка iX/Stevens

Источник: переписка / тред, который Андрей зафиксировал по памяти.

Тред 1 — кто/что обсуждал

Apologies for the duplicate there, you're right, it's just the 2 URLs.

@Brian Schiazza, when reviewing the list, please focus only on queries that are deemed prompts (filtered in Column B). Please use Column K to indicate whether each has been approved by your team or not. The same applies to the blog article opportunities tab as well.

@Michael Tkalych Forbes, agreed that the best path forward would be consolidating the Q&A pairs into a single FAQPage schema object, while still maintaining the separate accordion components on the front end. (screen grab below for more detail)

Next steps:

  • Update the schema logic to merge all FAQ Q&A pairs on the page into a single FAQPage entity (instead of generating one per accordion)
  • Ensure only one FAQPage object is present per URL to avoid duplication errors
  • Push the update to staging so we can revalidate via Rich Results + GSC

Once that's in place, we'll re-test and confirm everything is resolving as expected.

→ Изначальное предложение: merge всех Q&A в одну FAQPage entity.

Тред 2 — Michael нашёл shortcut (через 8:06 PM того же обсуждения)

I just found a major shortcut: this StackOverflow answer says that we will be compliant (no error in Google) even if we generate separate JSON-LD for each Accordion component as we currently do (i.e., no need to merge the question/answer pairs which would be quite difficult, the way our Next.js app is put together) if we just do one simple thing: add an "@id" property to each of the FAQPage objects, where its value is the same for each object (but different for each page). Simply using the URL path of the page as the "@id" value is a great solution.

I suggest that the existing ICUS-216-faq branch (which was the basis of PR 837) continue to be used for this hotfix, avoiding multiple branches for the same issue (multiple PRs for the same branch is no problem at all).

→ Принятое решение для PR #847:

  1. Не делать сложный merge в один объект.
  2. Добавить @id = URL страницы в каждый FAQPage JSON-LD.
  3. Переиспользовать branch ICUS-216-faq.

→ Это решение Michael — он же потом упомянет PR #847 в письме Alexis. То есть branch reuse был его идеей.

Что важно для встречи по squashing

  1. Branch reuse был не нашей инициативой — это явный совет от Michael Forbes ("multiple PRs for the same branch is no problem at all").

  2. Но "branch reuse без проблем" ≠ "переписывание истории без проблем". Эти две вещи — разные:

    • Branch reuse OK = открыть второй PR с того же brunch'а.
    • Squash/rebase после расшаривания НЕ OK = переписать историю, которую уже видели.

  3. Что именно произошло в PR #847 (нужно установить через git log):

    • Был ли squash-merge при PR #837?
    • Были ли force-push'и в ICUS-216-faq после открытия PR #847?
    • Был ли локальный rebase/squash перед открытием PR #847?

  4. К встрече сказать:

    • Branch reuse сделан по предложению самого Michael — это OK.
    • Squashing после расшаривания — обоснованная претензия Alexis. Признаём, поправим процесс.
    • Договариваемся: после первого расшаривания ветки (push на remote) — никакого rebase/force-push, всегда добавлять новые коммиты сверху. Squash — только при финальном merge через UI (чтобы история PR'а оставалась читаемой до момента merge).