Blog ScottGu - Tip / Trick: Napraw typowe problemy z SEO za pomocą rozszerzenia przepisywania adresu URL

1. Pomiar SEO Twojej witryny za pomocą Microsoft SEO Toolkit
2. Trafność wyszukiwania i podział adresów URL
3. 4 Naprawdę częste problemy z SEO, jakie mogą mieć Twoje witryny
4. Jak łatwo naprawić te problemy z SEO w ciągu 10 minut (lub mniej) za pomocą usługi IIS Rewrite
5. Scenariusz 1: Obsługa domyślnych scenariuszy dokumentów
6. Scenariusz 2: inna obudowa adresu URL
7. Scenariusz 3: końcowe ukośniki
8. Scenariusz 4: Kanoniczne nazwy hostów
9. 4 proste zasady ulepszonego SEO
10. streszczenie

Optymalizacja pod kątem wyszukiwarek (SEO) jest ważna dla każdej publicznie dostępnej strony internetowej. Duży procent ruchu do witryn pochodzi teraz bezpośrednio z wyszukiwarek, a poprawa trafności wyszukiwania w witrynie spowoduje, że więcej użytkowników odwiedzi witrynę z zapytań w wyszukiwarkach. Może to bezpośrednio lub pośrednio zwiększyć pieniądze, które zarabiasz na swojej stronie.

Ten wpis na blogu opisuje, w jaki sposób możesz korzystać z bezpłatnego Microsoft Rozszerzenie przepisywania adresu URL naprawić kilka typowych problemów SEO, które może mieć Twoja witryna. Zastosowanie 4 prostych zmian zajmuje mniej niż 15 minut (bez zmian kodu) Przepisz adres URL reguły do ​​Twojej witryny, a tym samym powodują, że wyszukiwarki przyciągają więcej użytkowników i ruch do Twojej witryny. Poniższe techniki działają równie dobrze z witrynami ASP.NET Web Forms i ASP.NET MVC. Współpracują również ze wszystkimi wersjami ASP.NET (a nawet pracują z treścią non-ASP.NET).

[Oprócz blogowania używam teraz Twittera do szybkich aktualizacji i udostępniania linków. Śledź mnie na: twitter.com/scottgu ]

Pomiar SEO Twojej witryny za pomocą Microsoft SEO Toolkit

Kilka miesięcy temu Blogowałem o wolnym Zestaw narzędzi SEO że wysłaliśmy. To przydatne narzędzie umożliwia automatyczne indeksowanie / skanowanie witryny pod kątem poprawności SEO, a następnie zaznacza wszelkie znalezione problemy z SEO. Gorąco polecam pobieranie i używanie tego narzędzia w stosunku do każdej publicznej witryny, na której pracujesz. Ułatwia to dostrzeżenie problemów SEO, które możesz mieć na swojej stronie, oraz wskazanie sposobów dalszej optymalizacji.

Poniżej znajduje się prosty przykład raportu, który uruchomiłem przeciwko jednej z moich witryn ( www.scottgu.com ) przed zastosowaniem reguł przepisywania adresów URL omówię później w tym wpisie na blogu:

Trafność wyszukiwania i podział adresów URL

Dwie ważne rzeczy, które oceniają wyszukiwarki podczas oceny „trafności wyszukiwania” w witrynie, to:

1. Ile innych witryn zawiera linki do treści. Wyszukiwarki zakładają, że jeśli wiele osób w sieci łączy się z twoją zawartością, jest to prawdopodobnie przydatne, a więc ważniejsze pod względem trafności.
2. Wyjątkowość treści znalezionych na Twojej stronie. Jeśli wyszukiwarki uznają, że treść jest powielana w wielu miejscach w Internecie (lub na wielu adresach URL w witrynie), może to spowodować utratę trafności treści.

Jedną z rzeczy, na które należy bardzo uważać, aby budować witryny publiczne, nie jest umożliwienie różnym adresom URL pobierania tej samej treści w witrynie. Takie postępowanie zaszkodzi obu powyższych sytuacjom.

W szczególności zezwolenie zewnętrznym stronom na łączenie się z tą samą treścią z wieloma adresami URL spowoduje, że liczba linków i ranking stron zostaną podzielone na różne adresy URL (dzięki czemu uzyskasz mniejszą rangę strony niż w przeciwnym razie, gdyby był tylko jeden adres URL). Nie zezwalanie zewnętrznym stronom na łączenie się z tobą na różne sposoby brzmi łatwo w teorii - ale możesz się zastanawiać, co to właściwie oznacza w praktyce i jak tego uniknąć.

4 Naprawdę częste problemy z SEO, jakie mogą mieć Twoje witryny

Poniżej znajdują się 4 naprawdę typowe scenariusze, które mogą spowodować, że witryna przypadkowo ujawni wiele adresów URL dla tej samej treści. Gdy tak się stanie, zewnętrzne strony z linkami do Twojej strony skończą się rozdzielać linki do stron na wiele adresów URL - w wyniku tego będziesz mieć niższy ranking stron w wyszukiwarkach niż na to zasługujesz.

Problem SEO nr 1: Dokument domyślny

Usługi IIS (i inne serwery internetowe) obsługują koncepcję „dokumentu domyślnego”. Pozwala to uniknąć konieczności jawnego określania strony, która ma być obsługiwana w katalogu głównym witryny / aplikacji lub w podkatalogu. Jest to wygodne - ale oznacza, że ​​domyślnie ta zawartość jest dostępna za pośrednictwem dwóch różnych odsłoniętych publicznie adresów URL (co jest złe). Na przykład:

http://scottgu.com/

http://scottgu.com/default.aspx

SEO Problem nr 2: Różne adresy URL

Twórcy stron internetowych często nie zdają sobie sprawy, że adresy URL są wrażliwe na wyszukiwarek internetowych. Oznacza to, że wyszukiwarki będą traktować następujące linki jako dwa zupełnie różne adresy URL:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Problem SEO nr 3: ukośne ukośniki

Rozważmy dwa poniższe adresy URL - na początku mogą wyglądać tak samo, ale są nieco inne. Końcowy ukośnik tworzy kolejną sytuację, która powoduje, że wyszukiwarki traktują adresy URL jako różne, a więc podzielone rankingi wyszukiwania:

http://scottgu.com

http://scottgu.com/

Problem SEO nr 4: kanoniczne nazwy hostów

Czasami witryny obsługują scenariusze, w których obsługują stronę internetową z zarówno przednim prefiksem nazwy hosta „www”, jak i samą nazwą hosta. Powoduje to, że wyszukiwarki traktują adresy URL jako różne i dzielące wyszukiwanie na kategorie:

http://scottgu.com/albums.aspx/

http://www.scottgu.com/albums.aspx/

Jak łatwo naprawić te problemy z SEO w ciągu 10 minut (lub mniej) za pomocą usługi IIS Rewrite

Jeśli nie byłeś ostrożny podczas kodowania stron, prawdopodobnie masz jeden (lub więcej) z powyższych problemów z SEO. Rozwiązanie tych problemów poprawi ranking trafności wyszukiwarki i zwiększy ruch w witrynie.

„Dobrą wiadomością” jest to, że naprawienie powyższych 4 problemów jest naprawdę łatwe przy użyciu Rozszerzenie przepisywania adresu URL . Jest to całkowicie bezpłatne rozszerzenie Microsoft dostępne dla IIS 7.x (w Windows Server 2008, Windows Server 2008 R2, Windows 7 i Windows Vista). Wspaniałą rzeczą w korzystaniu z rozszerzenia Rewrite IIS jest to, że pozwala on naprawić powyższe problemy * bez konieczności zmiany kodu w aplikacjach.

Możesz łatwo zainstalować Rozszerzenie przepisywania adresu URL w mniej niż 3 minuty za pomocą Instalator platformy Microsoft Web (bezpłatne narzędzie, które dostarczamy, które automatyzuje konfigurowanie serwerów internetowych i maszyn programistycznych). Po prostu kliknij zielony przycisk „Zainstaluj teraz” na Przepisz adres URL strona do zainstalowania na komputerze z systemem Windows Server 2008, Windows 7 lub Windows Vista:

Po zainstalowaniu przekonasz się, że nowa ikona „Przepisz URL” jest dostępna w narzędziu administracyjnym IIS 7:

Dwukrotne kliknięcie ikony otworzy panel administracyjny Przepisywanie URL - który wyświetli listę reguł przepisywania URL skonfigurowanych dla określonej aplikacji lub witryny:

Zwróć uwagę, że powyższa lista reguł przepisywania jest obecnie pusta (domyślnie przy pierwszej instalacji rozszerzenia). Możemy kliknąć przycisk „Dodaj regułę…” w prawym górnym rogu panelu, aby dodać i włączyć nową logikę przepisywania URL dla naszej witryny.

Scenariusz 1: Obsługa domyślnych scenariuszy dokumentów

Jednym z problemów SEO omówionych wcześniej w tym poście był scenariusz, w którym funkcja „domyślnego dokumentu” w usługach IIS powoduje przypadkowe udostępnienie dwóch adresów URL dla tej samej treści w witrynie. Na przykład:

http://scottgu.com/

http://scottgu.com/default.aspx

Możemy to naprawić, dodając nową regułę przepisywania IIS, która automatycznie przekieruje każdego, kto przejdzie do drugiego adresu URL, aby zamiast tego przejść do pierwszego. Ustawimy przekierowanie HTTP na „stałe przekierowanie” - które wskaże wyszukiwarkom, że powinny śledzić przekierowanie i użyć nowego adresu URL, do którego są przekierowywane jako identyfikator pobieranej treści.

Przyjrzyjmy się, jak możemy stworzyć taką regułę. Zaczniemy od kliknięcia linku „Dodaj regułę” na powyższym zrzucie ekranu. Spowoduje to wyświetlenie poniższego okna dialogowego:

W sekcji „Reguły przychodzące” wybierz szablon „Pusta reguła”, aby utworzyć nową niestandardową regułę przepisywania adresu URL. Spowoduje to wyświetlenie pustego okienka, jak poniżej:

Nie martw się - skonfigurowanie powyższej reguły jest łatwe. Poniższe 4 kroki wyjaśniają, jak to zrobić:

Krok 1: Nazwij regułę

Naszym pierwszym krokiem będzie nazwanie tworzonej reguły. Nadanie mu nazwy opisowej ułatwi późniejsze znalezienie i zrozumienie. Nazwijmy tę regułę regułą „Przepisz URL domyślnego dokumentu”:

Krok 2: Ustaw wyrażenie regularne pasujące do tej reguły

Naszym drugim krokiem będzie określenie filtra wyrażeń regularnych, który spowoduje wykonanie tej reguły, gdy przychodzący adres URL pasuje do wzorca wyrażenia regularnego. Nie martw się, jeśli nie jesteś dobry w używaniu wyrażeń regularnych - też je ssam. Sztuką jest znać kogoś, kto jest w nich dobry lub skopiować / wkleić je ze strony internetowej.

Poniżej określimy następujące wyrażenie regularne jako naszą regułę wzoru:

(. *?) /? Domyślnie .aspx $

Ten wzorzec pasuje do dowolnego ciągu URL, który kończy się na Default.aspx. „(. *?)” Dopasowuje dowolny poprzedzający znak zero lub więcej razy. ��/?” część mówi, aby dopasować symbol ukośnika zero lub jeden raz. Symbol „$” na końcu zapewni, że wzorzec będzie pasował tylko do ciągów, które kończą się na Default.aspx.

Połączenie wszystkich tych elementów wyrażeń regularnych pozwala tej regule działać nie tylko w katalogu głównym witryny (np http://scottgu.com/default.aspx ), ale także dla każdej aplikacji lub podkatalogu w witrynie (np http://scottgu.com/photos/default.aspx . Ponieważ pole wyboru „ignoruj ​​wielkość liter” jest zaznaczone, będzie pasować zarówno do „Default.aspx”, jak i „default.aspx” w adresie URL.

Jedną z ciekawych funkcji wbudowanych w edytor reguł jest przycisk „Wzorzec testowy”, który można kliknąć, aby wyświetlić okno dialogowe, które umożliwia przetestowanie kilku adresów URL z konfigurowaną regułą:

Powyżej dodałem adres URL „products / default.aspx” i kliknąłem przycisk „Test”. To da mi natychmiastową informację zwrotną o tym, czy reguła zostanie dla niej wykonana.

Krok 3: Skonfiguruj stałą akcję przekierowania

Następnie ustawimy akcję, która nastąpi, gdy nasz wzorzec wyrażenia regularnego pasuje do przychodzącego adresu URL:

W powyższym oknie dialogowym zmieniłem „Typ akcji”, który ma być „Przekierowaniem”. „Typ przekierowania” będzie trwałym przekierowaniem HTTP 301, co oznacza, że ​​wyszukiwarki będą go śledzić.

Ustawiłem także właściwość „Przekierowanie adresu URL” na:

{R: 1} /

Oznacza to, że chcemy przekierować klienta WWW żądającego oryginalnego adresu URL do nowego adresu URL, który ma pierwotnie żądaną ścieżkę URL - minus „Default.aspx” w nim. Na przykład prośby o http://scottgu.com/default.aspx zostanie przekierowany do http://scottgu.com/ i prośby o http://scottgu.com/photos/default.aspx zostanie przekierowany do http://scottgu.com/photos/

Konstrukcja wyrażenia regularnego „{R: N}”, gdzie N> = 0, nazywana jest wyrażeniem regularnym, a odniesienie do N, a indeks odniesienia wstecznego. W przypadku naszego wzorca „(. *?) /? Domyślnie .aspx $”, jeśli wejściowym adresem URL jest „products / Default.aspx”, to {R: 0} będzie zawierać „products / Default.aspx” i { R: 1} będzie zawierać „produkty”. Użyjemy tej wartości {R: 1} / jako adresu URL, do którego przekierowujemy użytkowników.

Krok 4: Zastosuj i zapisz regułę

Ostatnim krokiem jest kliknięcie przycisku „Zastosuj” w prawym górnym rogu narzędzia administracyjnego IIS - co spowoduje, że narzędzie utrwali regułę przepisywania adresu URL w głównym pliku web.config naszej aplikacji (pod <system.webServer / rewrite > sekcja konfiguracji):

<konfiguracja>
<system.webServer>
<rewrite>
<rules>
<nazwa reguły = "Dokument domyślny" stopProcessing = "true">
<match url = "(. *?) /? Default .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>

Ponieważ IIS 7.x i ASP.NET współdzielą te same pliki web.config, można po prostu skopiować / wkleić powyższy kod do plików web.config przy użyciu programu Visual Studio i pominąć konieczność uruchamiania narzędzia administracyjnego w całości. Dzięki temu dodawanie / wdrażanie reguł przepisywania adresów URL z aplikacjami ASP.NET jest bardzo proste.

Krok 5: Wypróbuj regułę

Teraz, gdy już zapisaliśmy regułę, wypróbujmy ją na naszej stronie. Wypróbuj następujące dwa adresy URL w mojej witrynie:

http://scottgu.com/

http://scottgu.com/default.aspx

Zauważ, że drugi adres URL automatycznie przekierowuje do pierwszego. Ponieważ jest to stałe przekierowanie, wyszukiwarki podążą za adresem URL i powinny zaktualizować ranking stron http://scottgu.com dołączyć linki do http://scottgu.com/default.aspx także.

Scenariusz 2: inna obudowa adresu URL

Innym powszechnym problemem SEO, który omówiłem wcześniej w tym poście, jest to, że adresy URL są wrażliwe na wielkość liter w wyszukiwarkach internetowych. Oznacza to, że wyszukiwarki będą traktować następujące linki jako dwa zupełnie różne adresy URL:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Możemy to naprawić, dodając nową regułę przepisywania IIS, która automatycznie przekieruje każdego, kto przejdzie do pierwszego adresu URL, aby zamiast tego przejść do drugiego (wszystkie małe litery). Tak jak poprzednio, ustawimy przekierowanie HTTP na „stałe przekierowanie” - które wskaże wyszukiwarkom, że powinny śledzić przekierowanie i użyć nowego adresu URL, do którego są przekierowywane jako identyfikator pobieranej treści.

Aby utworzyć taką regułę, ponownie klikniemy link „Dodaj regułę” w narzędziu administracyjnym Przepisz URL. Spowoduje to ponowne wyświetlenie okna dialogowego „Dodaj regułę”:

W przeciwieństwie do poprzedniego scenariusza (w którym stworzyliśmy „pustą regułę”), w tym scenariuszu możemy skorzystać z wbudowanego szablonu reguły „Wymuszaj małe adresy URL”. Po kliknięciu przycisku „ok” zobaczymy następujące okno dialogowe z pytaniem, czy chcemy utworzyć regułę, która wymusza stosowanie małych liter w adresach URL:

Kiedy klikniemy przycisk „Tak”, otrzymamy wcześniej napisaną regułę, która automatycznie wykonuje stałe przekierowanie, jeśli przychodzący adres URL zawiera w sobie duże litery - i automatycznie wysyła użytkowników do mniejszej wersji adresu URL:

Możemy kliknąć przycisk „Zastosuj”, aby skorzystać z tej reguły „jak jest” i mieć zastosowanie do wszystkich przychodzących adresów URL do naszej witryny.

Bo mój www.scottgu.com strona używa formularzy ASP.NET Web Forms, zamierzam wprowadzić jedną małą zmianę do reguły, którą wygenerowaliśmy powyżej - która ma na celu dodanie warunku, który zagwarantuje, że adresy URL do wbudowanego modułu obsługi „WebResource.axd” ASP.NET są wykluczone z naszej rozróżnialności wielkości logiki URL. Adresy URL do obsługi WebResource.axd będą pochodzić tylko z kontrolek serwera emitowanych z moich stron - i nigdy nie będą linkowane z zewnętrznych stron. Chociaż moja witryna będzie nadal działać poprawnie, jeśli przekierujemy te adresy URL automatycznie, to nie jest to konieczne i doda dodatkowe przekierowanie HTTP do wielu moich stron.

Dobrą wiadomością jest to, że dodanie warunku uniemożliwiającego moją regułę przepisywania adresów URL z niektórymi adresami URL jest łatwe. Po prostu musimy rozwinąć sekcję „Warunki” w powyższym formularzu

Następnie możemy kliknąć przycisk „Dodaj”, aby dodać klauzulę warunku. Spowoduje to wyświetlenie okna dialogowego „Dodaj warunek”:

Powyżej wpisałem {URL} jako wejście warunkowe - i powiedziałem, że ta reguła powinna być wykonywana tylko wtedy, gdy URL nie pasuje do wzorca wyrażenia regularnego zawierającego ciąg „WebResource.axd”. Zapewni to, że adresy URL WebResource.axd do mojej witryny będą mogły działać poprawnie bez konieczności ponownego zapisywania adresu URL, aby były małe.

Uwaga: jeśli masz w swojej witrynie statyczne zasoby (takie jak odwołania do plików .jpg, .css i .js), które obecnie używają wielkich liter, prawdopodobnie będziesz chciał dodać dodatkowe klauzule filtrowania warunku, aby adresy URL do nich również miały Nie można przekierować na małe litery (wystarczy dodać reguły dla wzorców takich jak .jpg, .gif, .js itp.). Twoja witryna będzie nadal działać poprawnie, jeśli te adresy URL zostaną przekierowane na małe litery (co oznacza, że ​​witryna nie zostanie zerwana) - ale spowoduje to dodatkowe przekierowanie HTTP w witrynie w przypadku adresów URL, które nie muszą być przekierowywane do Powody SEO. Dodanie klauzuli warunkowej ma sens.

Gdy kliknę przycisk „ok” powyżej i zastosujemy naszą regułę przepisywania małych liter, narzędzie administracyjne zapisze następującą dodatkową regułę w naszym pliku web.config:

<konfiguracja>
<system.webServer>
<rewrite>
<rules>

<nazwa reguły = "Dokument domyślny" stopProcessing = "true">
<match url = "(. *?) /? Default .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</rule>

<nazwa reguły = "Adresy małych liter" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<warunki logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" url = "{ToLower: {URL}}" />
</rule>

</rules>
</rewrite>
</system.webServer>
</configuration>

Wypróbuj regułę

Teraz, gdy już zapisaliśmy regułę, wypróbujmy ją na naszej stronie. Wypróbuj następujące dwa adresy URL w mojej witrynie:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Zauważ, że pierwszy adres URL (który ma duże „A”) automatycznie przekierowuje do wersji URL o mniejszych rozmiarach.

Scenariusz 3: końcowe ukośniki

Innym powszechnym problemem SEO, który omówiłem wcześniej w tym poście, jest scenariusz końcowych ukośników w adresach URL. Końcowy ukośnik tworzy kolejną sytuację, która powoduje, że wyszukiwarki traktują adresy URL jako różne, a więc podzielone rankingi wyszukiwania:

http://scottgu.com

http://scottgu.com/

Możemy to naprawić, dodając nową regułę przepisywania IIS, która automatycznie przekierowuje każdego, kto nawiguje do pierwszego adresu URL (który nie ma końcowego ukośnika), aby zamiast tego przejść do drugiego adresu. Tak jak poprzednio, ustawimy przekierowanie HTTP na „stałe przekierowanie” - które wskaże wyszukiwarkom, że powinny śledzić przekierowanie i użyć nowego adresu URL, do którego są przekierowywane jako identyfikator pobieranej treści.

Aby utworzyć taką regułę, ponownie klikniemy link „Dodaj regułę” w narzędziu administracyjnym Przepisz URL. Spowoduje to ponowne wyświetlenie okna dialogowego „Dodaj regułę”:

Narzędzie administracyjne do przepisywania adresów URL ma wbudowany szablon reguły „Dołącz lub usuń końcowy symbol ukośnika”.

Kiedy go zaznaczymy i klikniemy przycisk „ok”, zobaczymy następujące okno dialogowe, w którym pytamy nas, czy chcemy utworzyć regułę, która automatycznie przekierowuje użytkowników na adres URL z końcowym ukośnikiem, jeśli nie jest obecny:

Kiedy klikniemy przycisk „OK”, otrzymamy wcześniej napisaną regułę, która automatycznie wykonuje stałe przekierowanie, jeśli adres URL nie ma końcowego ukośnika - i jeśli adres URL nie jest przetwarzany przez katalog lub plik.

Podobnie jak w naszej poprzedniej regule przepisywania w niższej obudowie dodamy jedną dodatkową klauzulę warunku, która wyklucza adresy URL WebResource.axd z przetwarzania przez tę regułę. Pozwoli to uniknąć niepotrzebnego przekierowania dla tych adresów URL.

Spowoduje to zapisanie następującej dodatkowej reguły do ​​naszego pliku web.config:

<konfiguracja>
<system.webServer>
<rewrite>
<rules>

<nazwa reguły = "Dokument domyślny" stopProcessing = "true">
<match url = "(. *?) /? Default .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</rule>

<nazwa reguły = "Adresy małych liter" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<warunki logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" url = "{ToLower: {URL}}" />
</rule>

<nazwa reguły = "Trailing Slash" stopProcessing = "true">
<match url = "(. * [^ /]) $" />
<warunki logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{REQUEST_FILENAME}" matchType = "IsDirectory" negate = "true" />
<add input = "{REQUEST_FILENAME}" matchType = "IsFile" negate = "true" />
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" url = "{R: 1} /" />
</rule>

</rules>
</rewrite>
</system.webServer>
</configuration>

Wypróbuj regułę

Teraz, gdy już zapisaliśmy regułę, wypróbujmy ją na naszej stronie. Wypróbuj następujące dwa adresy URL w mojej witrynie:

http://scottgu.com

http://scottgu.com/

Zauważ, że pierwszy adres URL (który nie ma ukośnika końcowego) automatycznie wykonuje przekierowanie do adresu URL z końcowym ukośnikiem. Ponieważ jest to stałe przekierowanie, wyszukiwarki będą śledzić adres URL i aktualizować ranking strony.

Scenariusz 4: Kanoniczne nazwy hostów

Ostatnim problemem SEO, który omówiłem wcześniej, są scenariusze, w których witryna działa zarówno z wiodącym przedrostkiem nazwy hosta „www”, jak i samą nazwą hosta. Powoduje to, że wyszukiwarki traktują adresy URL jako różne i dzielące wyszukiwanie na kategorie:

http://www.scottgu.com/albums.aspx

http://scottgu.com/albums.aspx

Możemy to naprawić, dodając nową regułę przepisywania IIS, która automatycznie przekieruje każdego, kto przejdzie do pierwszego adresu URL (który ma prefiks www), aby zamiast tego przejść do drugiego adresu URL. Tak jak poprzednio, ustawimy przekierowanie HTTP na „stałe przekierowanie” - które wskaże wyszukiwarkom, że powinny śledzić przekierowanie i użyć nowego adresu URL, do którego są przekierowywane jako identyfikator pobieranej treści.

Aby utworzyć taką regułę, ponownie klikniemy link „Dodaj regułę” w narzędziu administracyjnym Przepisz URL. Spowoduje to ponowne wyświetlenie okna dialogowego „Dodaj regułę”:

Narzędzie administracyjne do przepisywania adresów URL ma wbudowany szablon reguły „Canonical domain name”.

Po wybraniu go i kliknięciu przycisku „ok” zobaczymy następujące okno dialogowe z pytaniem, czy chcemy utworzyć regułę przekierowania, która automatycznie przekierowuje użytkowników na adres URL głównej nazwy hosta:

Powyżej wprowadzam podstawowy adres URL, który chcę udostępnić w sieci: scottgu.com. Kiedy klikniemy przycisk „OK”, otrzymamy wcześniej napisaną regułę, która automatycznie wykonuje stałe przekierowanie, jeśli URL ma inny wiodący prefiks nazwy domeny.

Spowoduje to zapisanie następującej dodatkowej reguły do ​​naszego pliku web.config:

<konfiguracja>
<system.webServer>
<rewrite>
<rules>

<nazwa reguły = "Nazwa hosta armatniego">
<match url = "(. *)" />
<warunki logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{HTTP_HOST}" pattern = "^ scottgu. $ $" negate = "true" />
</conditions>
<action type = "Redirect" url = " http://scottgu.com/{R:1} ” />
</rule>

<nazwa reguły = "Dokument domyślny" stopProcessing = "true">
<match url = "(. *?) /? Default .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</rule>

<nazwa reguły = "Adresy małych liter" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<warunki logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" url = "{ToLower: {URL}}" />
</rule>

<nazwa reguły = "Trailing Slash" stopProcessing = "true">
<match url = "(. * [^ /]) $" />
<warunki logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{REQUEST_FILENAME}" matchType = "IsDirectory" negate = "true" />
<add input = "{REQUEST_FILENAME}" matchType = "IsFile" negate = "true" />
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" url = "{R: 1} /" />
</rule>

</rules>
</rewrite>
</system.webServer>
</configuration>

Wypróbuj regułę

Teraz, gdy już zapisaliśmy regułę, wypróbujmy ją na naszej stronie. Wypróbuj następujące dwa adresy URL w mojej witrynie:

http://www.scottgu.com/albums.aspx

http://scottgu.com/albums.aspx

Zauważ, że pierwszy URL (który ma prefiks „www”) teraz automatycznie przekierowuje do drugiego adresu URL, który nie ma prefiksu www. Ponieważ jest to stałe przekierowanie, wyszukiwarki będą śledzić adres URL i aktualizować ranking strony.

4 proste zasady ulepszonego SEO

Powyższe 4 zasady są dość łatwe do skonfigurowania i powinny zająć mniej niż 15 minut na skonfigurowanie istniejących już witryn.

Piękno korzystania z rozwiązania, takiego jak rozszerzenie do przepisywania adresów URL, polega na tym, że możesz z niego korzystać bez konieczności zmiany kodu w swojej witrynie internetowej - bez konieczności łamania jakichkolwiek istniejących linków wskazujących już na Twoją stronę. Użytkownicy śledzący istniejące linki zostaną automatycznie przekierowani do nowych adresów URL, które chcesz opublikować. Wyszukiwarki zaczną nadawać Twojej witrynie wyższy ranking trafności wyszukiwania - co spowoduje wyświetlenie Twojej witryny w wynikach wyszukiwania i zwiększenie ruchu.

Dostosowywanie reguł przepisywania adresów URL jest łatwe do zrobienia, edytując bezpośrednio plik web.config lub po prostu kliknij dwukrotnie ikonę przepisywania adresu URL w narzędziu administracyjnym IIS 7.x i wyświetli listę wszystkich aktywnych reguł dla Twojej sieci -strona lub aplikacja:

Kliknięcie dowolnej z powyższych reguł spowoduje otwarcie edytora reguł i pozwolenie na dalsze modyfikowanie / dostosowywanie / zapisywanie ich.

streszczenie

Pomiar i ulepszanie SEO to coś, co każdy deweloper budujący publicznie dostępną stronę internetową musi przemyśleć i skupić się na nim. Jeśli jeszcze tego nie zrobiłeś, pobierz i użyj Zestaw narzędzi SEO analizować SEO swoich witryn już dziś.

Nowe funkcje routingu URL w ASP.NET MVC i ASP.NET Web Forms 4 znacznie łatwiej budować aplikacje, które mają większą kontrolę nad publikowanymi adresami URL. Narzędzia takie jak Rozszerzenie przepisywania adresu URL o czym mówiłem w tym wpisie na blogu znacznie ułatwia ulepszanie adresów URL publikowanych z witryn, które już zbudowałeś - bez konieczności zmiany dużej ilości kodu.

The Rozszerzenie przepisywania adresu URL zapewnia szereg dodatkowych wspaniałych możliwości - daleko poza samym SEO -. Będę omawiać te dodatkowe możliwości bardziej w przyszłych postach na blogu.

Mam nadzieję że to pomoże,

Scott