Сергей Хлопов

Статические ссылки на текущий класс, такие как self:: или __CLASS__, вычисляются используя класс, к которому эта функция принадлежит, как и в том месте, где она была определена
...
Позднее статическое связывание пытается устранить это ограничение, предоставляя ключевое слово, которое ссылается на класс, вызванный непосредственно в ходе выполнения.

Позднее статическое связывание

Решение:

public static function getMessage(): string
{
  return 'message - ' . static::getString();
}

потому что это не исполняемый файл

Исполняемый файл это файл который исполняет операционная система.
в данном случае РНР файл исполняется не операционной системой, а веб-сервером, и права на исполнение к нему не имеют отношения вообще никакого

Методы catalog и services отличаются одним словом, как минимум можно подумать как их оьбьеденить в один. Для хлебных крошек есть нормальный composer пакет, который позволяет не писать в контроллерах запрос на получение, а вынести логику в отдельный файл.

Я думаю именно в данном коде всё ок, но судя по названиям должно быть 3 controller , но раз уж есть желание заморачиваться то попробуйте запросы делать в scope и в контроле передать с запросом в view

Вынести логику в сервисы.
Метод сервиса возвращает массив данных, который потом передаётся во view.

Что говорит Ларавел? Он говорит разделить на контроллеры. Для продуктов ProductController и т.д. Именовать методы index show update и т.д. Массив данных для вьюхи можно получать из своего класса, но можно и так оставить если в контроллере данных мало. Я бы пересмотрел логику формирования данных и наименований т.к. вроде задач сложных нет, но процессы непонятные какие-то $arrayUrl alias entity ит.д.

можно
делать не стоит если не умеете склеивать расклеивать

от условного 1,0 по СЕО от двух будет 0,45 + 0,35 например , но никогда не 1

Так как сайты будут одной тематики это означает, что у них будет пересечение семантики (ключевых запросов). Для Яндекса это будет сигналом для аффилирования двух ресурсов.

Как не попасть под фильтр аффилирования:

• Работать с сайтами с разных IP (на всякий случай).
  
• Заходить с разных аккаунтов Яндекс Вебмастера (или с агентского, по гостевому доступу).
  
• Полностью изменить контактные данные, лого, и др. комерческие факторы ранжирования, чтобы убедить ПС, что это два разных сайта.
  
• Работать с контентом и наполнением сайта, пересечения должно быть минимум.
  

И ещё придется работать и с сылочным профилем этих сайтов, чтобы ПС не подумала, что это сетка ради ссылок и т.д. и т.п. Если есть время и деньги — то можно попробовать занять несколько мест в выдаче, но если не хотите заморачиваться, то лучше не стоит, т.к. заработаете фильтр и все).

Тут уже думайте сами, решайте сами!

Да, всю логику нужно выносить в отдельные классы.

Задача контроллера - определить, какую информацию исходя из полученного запроса показывать. Даже валидацию лучше выносить в отдельный Request, потому что это уже не задача контроллера.

Я обычно делаю сервисы, как вы написали, но еще и:
/app/Repositories - репозитории. Позволяют в контроллере брать информацию из БД, типа такого:
$this->postsRepository->getPostsForHomePageLoop();

А вообще способов много - можете прочитать про паттерны проектирования.

Главное помните про SRP из SOLID. Что каждый класс отвечает за свою функциональность и не может выходить за её рамки.

Используй 4 и 5 способ из статьи. В идеале в контроллере должна быть только валидация через FormRequest с передачей данных в сервисный слой.

class ClientReportController extends Controller
{
    private $reportService;
    public function __construct(ReportService $service)
    {
        $this->reportService = $service;
    }
    public function index(Request $request)
    {
        $entries = $this->reportService->getTransactionReport($request->input('project'));
        // ...
    }
    public function income(Request $request)
    {
        $entries = $this->reportService->getIncomeReport($request->input('project'));
        // ...
    }
}

отвечу, только исходя из своего опыта.
Сначала опишу варианты, которые вижу на практике, затем выскажу мнение.

Вариант №1: В выдаче ТОП-5 встречаю сайты со структурой, где страница "домен/tovar" отдает 404.
Причина скорее всего в том, что каждая страница сайта продвигается по своей группе запросов.
Поэтому, если "домен/tovar" не продвигается по запросам, то ответ 404 не критичен.

Вариант №2: Есть пул внутренних факторов (именно о них сейчас речь), которые включают придание бОльшего веса тем страницам, которые имеют вложенность в URL cо страниц, которые ниже по иерархии - это например, "домен/katalog//product-alias/product-id". Поэтому считается, что "/katalog" получает хороший вес, если отдает 200ОК, в этом случае.

Вариант, который предлагаете вы не рекомендую использовать.
Просто потому, что если страница должна отдавать 404, значит она должна его отдавать и менять ее на 301 не стоит. Занимайтесь качеством карточек товаров, размещайте блоки внутренней перелинковки м/д карточки-разделы, карточки-карточки и будет вам счастье!)

Миддлвейры не предназначены для пропихивания чего-то в контроллер. Они обрабатывают реквест и либо перекидывают его следующему миддлвейру (и так до конца), либо возвращают ответ (который прервет исполнение).

Если этот адский велосипед вы пишете только для того, чтобы авторизовывать пользователей и получать инстанс текущего пользователя, то в Ларе это уже из коробки реализовано.

Вам нужно почитать про атрибут canonical.

1. Работа над личным брендом: Высокая репутация в профессиональных сообществах повышает привлекательность для нанимателей.
   
2. Улучшение существующих знаний: Хочешь что-то понять, объясни другому.
   
3. Приобретение новых знаний: Специализация замыкает в узком спектре задач и проблем, а Q&A-сервисы - это источник задач и проблем из самых разных областей и иногда под самыми неожиданными углами.
   
4. Альтруизм: Большинству из нас кто-то помогал в начале пути, пришло время возвращать долг и делать свой скромный вклад в рост кадров.
   

Ещё бывают поклонники какой-то технологии, которые делают вклад в её развитие, продвижение и популяризацию, помогая другим с ней разобраться. Но лично я за это пока не брался, хотя мысли есть.

Для чего просиживаете на тостере по 5-6 часов в день?

Я в среднем раз в полчаса-час заглядываю. Если находится интересный вопрос, могу потратить на него минут 10. Некоторые на перекуры больше времени тратят.