Skocz do zawartości

pumpernikiel

Nowi Forumowicze
  • Postów

    14
  • Dołączył

  • Ostatnia wizyta

Osiągnięcia pumpernikiel

  1. Taki mały żarcik Dziś wiadomo - content i jego jakość ma zdecydowany wpływ na pozycję w rankingu. Mimo wszystko (podobno) tego typu bzdury nadal są brane pod uwagę co w teorii może mieć wpływ o przesunięcie 1 pozycję w górę, co w niektórych przypadkach mogło by być decydujące czy wynik trafi się na np. 3 czy 2 stronę w wynikach W sumie w czasach gdy "poprawne treści" są coraz częściej generowane przez AI pod kątem SEO, pytanie czy tego typu "bzdury" nie dostaną na powrót większej "siły" którą miały kiedyś ?
  2. Jesteście 100% pewni ? Google przy indeksacji bierze pod uwagę wystąpienia słów kluczowych w samym adresie (również). Pytanie zatem czy krótszy adres "domena.pl/strona" vs "domena.pl/strona.html" lub "domena.pl/strona.php" nie wypadnie lepiej pod kątem "procenta wystąpień słów kluczowych w stosunku do ilości znaków całego adresu" co mogło by mieć "jakiś" wpływ na rezultat. To o scenariuszu gdy "strona" w adresie domena.pl/strona jest jednocześnie słowem kluczowym
  3. Na konkretne rozwiązanie SSL nie miałem wpywu. Administrator serwera sam wykupywał zgodnie z swoimi preferencjami refakturując usługę do ogólnych kosztów utrzymania. O ile pamiętam to wychodziło całkiem korzystnie w stosunku do wykupienia certyfikatu samemu.
  4. Zaś ostatnio zabrałem się na zmianę tych adresów do postaci bez końcówek "*.php" czego efektem było czasowe "duplicate content". Także cała akcja to rzecz jasna nie "optymalizacja dla każdego", tylko przesunięte w czasie działanie naprawcze dla tego konkretnego przypadku. Teraz już chyba jasne
  5. Dokładnie tak jak piszesz. Przejście było z czystego HTML na php i oczywiście tylko o te końcówki w adresie chodzi. Mogłem na etapie przejścia z czystego html na php od razu pozmieniać adresy "na bez końcówki *.php" ale wtedy tego nie zrobiłem, ze dwa lata temu doszło wykupienie certyfikatu i adresy z "https". Plusem po tej zmianie jest wykorzystanie siły starych linków zewnętrznych o różnej strukturze do indeksacji tych samych stron.
  6. Ten ostatni skrypt działa i widzę już efekty. Dla kolejnych podstron kara za "duplicate content" powoli wypada. Cała operacja miała sens o tyle że w przeciągu lat struktura strony pod kątem nazw i adresów się nie zmieniła, ale doszło wykupienie certyfikatu (https), , zmiana technologii z html na php. Linki zewnętrzne w sieci, np. na forach internetowych do (fizycznie) tych samych stron mają przeróżne formaty...
  7. Nie CMS tylko htaccess. Wszystkie linki wewnętrzne strony oraz ich opisy "canonical" zostały sprowadzone do postaci https://www.domena/strona skryptem w notepad++ przelecianym po plikach. Fizycznie pod tymi linkami są pliki *.php. Póki co wygląda na to że skrypt htaccess działa dobrze, czekam na reakcję google aż zindeksuje stronę na nowo.
  8. Pierwsza propozycja Grok'a nie działała dla żadnych podstron poza domeną główną (efekt not found). Finalna działająca wersja po poprawieniu się przez Grok'a wygląda tak: DirectoryIndex index.php RewriteEngine On RewriteBase / # Przekierowanie z HTTP na HTTPS i z non-www na www RewriteCond %{HTTP_HOST} !^www\. [NC,OR] RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC] RewriteRule ^ https://www.%1%{REQUEST_URI} [R=301,L] # Usuwanie rozszerzeń .html i .php RewriteCond %{THE_REQUEST} \s/+(.+?)\.(html|php)\s [NC] RewriteRule ^ /%1 [R=301,L] # Przepisanie żądań bez rozszerzeń na pliki .php (jeśli istnieją) RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME}.php -f RewriteRule ^(.+)$ $1.php [L]
  9. O tym PHP zacząłem pisać zanim odpowiedziałeś dając swoją propozycję kodu htaccess (nie byłem pewien czy z tym przekierowaniem 301 miałeś na mysli zmianę w htaccess). Co do AI dobra sugestia. Grok na szczegółowo zadane pytanie odpowiedział tak: Aby spełnić podane wymagania, należy zmodyfikować plik .htaccess, dodając reguły, które: Przekierowują z HTTP na HTTPS. Dodają „www” do adresu, jeśli go brakuje. Usuwają rozszerzenia .html i .php z adresów URL. Zapewniają, że roboty indeksują tylko wersję bez rozszerzeń, używając przekierowań 301 (stałych), aby uniknąć duplikacji treści. Poniżej znajduje się zmodyfikowany kod .htaccess, który realizuje te wymagania: apache DirectoryIndex index.php RewriteEngine On # Przekierowanie z HTTP na HTTPS i z non-www na www RewriteCond %{HTTP_HOST} !^www\. [NC,OR] RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC] RewriteRule ^ https://www.%1%{REQUEST_URI} [R=301,L] # Usuwanie rozszerzeń .html i .php RewriteCond %{REQUEST_URI} \.(html|php)$ [NC] RewriteRule ^(.+)\.(html|php)$ $1 [R=301,L] # Obsługa żądań bez rozszerzeń (przepisanie do pliku .php, jeśli istnieje) RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME}.php -f RewriteRule ^(.+)$ $1.php [L] Wyjaśnienie działania: Przekierowanie na HTTPS i www: Pierwsza reguła (RewriteCond %{HTTP_HOST} !^www\. [NC,OR] i RewriteCond %{HTTPS} off) sprawdza, czy adres nie zawiera „www” lub używa HTTP zamiast HTTPS. Następnie przekierowuje (R=301) na wersję z „https://www.”, zachowując resztę adresu URL. Usuwanie rozszerzeń .html i .php: Druga reguła (RewriteCond %{REQUEST_URI} \.(html|php)$ [NC]) sprawdza, czy URL kończy się na .html lub .php (ignorując wielkość liter dzięki [NC]). Następnie przekierowuje (R=301) na wersję bez rozszerzenia, np. podstrona.html → podstrona. Obsługa żądań bez rozszerzeń: Trzecia reguła sprawdza, czy żądany URL nie wskazuje na istniejący plik (!-f) ani katalog (!-d), ale czy istnieje plik .php o tej nazwie (%{REQUEST_FILENAME}.php -f). Jeśli tak, wewnętrznie przepisuje żądanie na plik .php (np. podstrona → podstrona.php) bez zmiany adresu w przeglądarce (dzięki fladze [L]). Dlaczego przekierowanie 301? Przekierowanie 301 (stałe) jest używane, aby poinformować roboty wyszukiwarek (np. Google), że adres docelowy (z „https”, „www” i bez rozszerzenia) jest ostateczny. To zapobiega indeksowaniu wersji z .html, .php, bez „www” lub z HTTP, eliminując problem duplikacji treści. Przykłady działania: http://domena.pl/podstrona.html → https://www.domena.pl/podstrona https://domena.pl/podstrona.php → https://www.domena.pl/podstrona http://www.domena.pl/podstrona → https://www.domena.pl/podstrona https://domena.pl/podstrona → https://www.domena.pl/podstrona Uwagi: Upewnij się, że serwer ma włączony moduł mod_rewrite (Apache). Przetestuj reguły w środowisku testowym, aby upewnić się, że działają poprawnie dla Twojej konfiguracji. Jeśli strona korzysta z innych rozszerzeń (np. .htm), można je dodać do reguły usuwania rozszerzeń, np. RewriteCond %{REQUEST_URI} \.(html|htm|php)$ [NC]. Plik .htaccess powinien znajdować się w głównym katalogu domeny. Ten kod zapewnia, że adresy będą zawsze w formacie https://www.domena.pl/podstrona, a roboty wyszukiwarek będą indeksować tylko tę wersję.
  10. Harry, miałeś na myśli dodanie do podstron <?php header("HTTP/1.1 301 Moved Permanently"); header("Location: https://www.strona.pl/podstrona"); exit(); ?> Czy zmianę w htaccess ? Zakomentowanie starej linijki ukrywania rozszerzeń php ( RewriteRule ^([^\.]+)$ $1.php [NC,L] ) i wrzucenie tego co zaproponowałeś nie działa. Efektem jest błąd 404 i wyrzucenie w pasku adresu pełnego adresu serwera hostingu. Będę wdzięczny jak wrzucisz całą treść htaccess po zmianie
  11. Harry, temat "robots.txt" jasny, po prostu wywalam wpisy disallow. Co do htaccess będę wdzięczny jeśli przekleisz zmodyfikowaną linijkę tak jak powinna brzmieć RewriteRule ^([^\.]+)$ $1.php [R=301,L] O to chodzi ? O to chodzi ? Reszta htacces OK ? RewriteRule ^([^\.]+)$ $1.php [R=301,L]
  12. Rozumiem że wujek google dwa adresy .../podstrona .../podstrona.php potraktuje jako dwa odrębne adresy mimo dokładnie tej samej treści ? Chyba że link kanoniczny jest jawnie zadeklarowany (zgodny z jednym z nich) ?
  13. Witam wszystkich. Ostatnio dokonałem na swojej stronie zmian polegających na: - zmianie rozszerzeń podstron z *.php na bez //przekierowanie htaccess - dodaniu linków kanonicznych w każdej z podstron wg schematu <link rel="canonical" href="https://www.strona.pl/podstrona"> gdzie wcześniej tych linków kanonicznych nie było w ogóle, zaś linki podston indeksowały się razem z rozszerzeniem "*.php" Aktualnie .htaccess wygląda tak: DirectoryIndex index.php RewriteEngine On RewriteCond %{HTTP_HOST} !^$ RewriteCond %{HTTP_HOST} !^www. [NC] RewriteCond %{HTTPS}s ^on(s)| RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^([^\.]+)$ $1.php [NC,L] Zaś robots.txt wygląda tak: User-agent: * Disallow: /*.php$ Disallow: /en/*.php$ Sitemap: https://www.strona.pl/sitemap.xml //zawiera tylko linki zgodne z kanonicznymi z www i https (wcześniej podstrony w sitemap miały rozszerzenia ".php") Moje pytanie pytanie brzmi - czy słusznie blokuję w "robots.txt" linki z rozszerzeniem *.php ? Zrobiłem to, ponieważ zauważyłem że SearchConsole ma tendencję do indeksowania tych samych linków podwójnie - z rozszerzeniem i bez nich, tak więc chciałem zostawić tylko te bez rozszerzeń. Moje zmiany doprowadziły do tego że strona czasowo spadła w wynikach, wszystkie linki z rozszerzeniem *.php zgłosiłem również do usunięcia w SearchConsole. Linki kanoniczne w podstronach oraz wpisy disallow w robots były dodane później niż przekierowania na strony bez *.php więc być może duplikaty doprowadziły do spadku w wynikach, czego pewien nie jestem... Czy dobrze zrobiłem i po prostu muszę czekać czy też powinienem usunąć z robots.txt te wpisy "disallow php" nie przejmując się że później są z tego duplikaty linków w SearchConsole ? Czy htaccess pod kątem SEO jest wg was OK ?
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę. Warunki użytkowania Polityka prywatności