• User Newbie

    Troppe variabile GET: consgili e soluzioni.

    Ciao a tutti,
    visto che uso necessariamente e abbastanza massivamente i passaggi di variabile GET di php vorrei ottimizzare l'invio di questi parametri del mio sito.

    Avevo pensato ad una soluzione appoggiandomi sul mod-rewriting offerto da Apache.
    Sicchè la mia query-string che passo al server da cosi:
    mio-sito.com/it?a=115&b=122&c=Hello
    potrebbe diventare ottimizzata:
    mio-sito.com/it/compose:🅰:115:🅱:122::c::Hello.html**

    (ho messo come caratteri sentinella due duepunti "::" e alla fine un bel .html :), e vabbè, una stringa iniziale, "compose" ).

    Volevo sapere se con questa ottimizzazione potrei avere benefici di maggior indicizzazione da parte di Google.

    Spiego a parole come potrei realizzare questa ottimizzazione (devo ancora buttare giù qualcosa!).

    1. Costruisco il mio bel form il HTML con method = POST.
    2. Una volta fatto il submit, i dati vengono passati per esempio alla pagina <parsing.php>
    3. Questa pagina non contine codice HTML, solo PHP: prevelerà le variabile $_POST[] e costruirà la stringa che ho mostrato prima.
    4. Passo la stringa alla homepage (o dove altro voglio) tramite la direttiva header();

    L'utente non si accorge della trafila e vede direttamente la pagina di destionazion.. Ma Google?
    Ora non so cosa pensa (o vede) Google quando si becca un header("Location: ... ") ... chiedo a voi 🙂

    Mi conviene fare una cosa del genere? Che tipo di redicect genera un' header("Location: ... ") (da 300 a 307) ?

    Grazie in anticipo!!

    Dominio:
    example.com

    Motori:
    Google

    Prima indicizzazione o attività:
    null

    Cambiamenti effettuati:
    null

    Eventi legati ai link:
    null

    Sito realizzato con:
    php

    Come ho aumentato la popolarità:
    null

    Chiavi:
    null

    Sitemaps:
    No


  • Super User

    Ciao, non conosco PHP, ma dal nome $_POST[] non dovrebbe ricevere i dati inviati con method="post"? Tu invece stai parlando del method="get".

    Non condivido la scelta dei due punti come separatori, nelle SERP l'utente si trova una cosa strana, e di fronte ad ogni stranezza può allarmarsi e domandandarsi "è una pagina?", "che ci sia un virus?" ecc.

    Vantaggi? Si, nella misura in cui le pagine finali saranno prima o poi da te o qualcun altro linkate in social bookmarks, siti ecc.
    Se vuoi amplificarli, crea un tag cloud delle parole più cercate.

    Io direi che è meglio il redirect 301.

    Se posso aggiungere un consiglio, normalizza i valori e rimuovi le variabili che l'utente non ha valorizzato in modo da ridurre al minimo le possibili pagine duplicate, e avere URL più comprensibili e pulite.


  • User Newbie

    Grazie per la risposta.
    Attualmete il mio sito passa i valori tramite il metodo GET.
    Volevo usare il metodo POST come possibile soluzione.
    Non so se ci siamo capiti: il form invierebbe le informazioni col metodo POST a una pagina PHP, la quale le elabora producendo una URL ottimizzata da passare al browser tramite redirect (in questo modo se ho un campo non valorizzato, lo escudo dalla URL).

    I due punti erano solo un'esempio. Posso scegliere opportunamente qualche altro carattere o serie di caratteri sentinella (spero di fare una scelta giusta!).

    normalizza i valori e rimuovi le variabili che l'utente non ha valorizzato in modo da ridurre al minimo le possibili pagine duplicateQuesto è un'ottimo consiglio. In effetti attualmente ho parecchie variabili che assumono, diciamo valori di default, e che appaiono nella url dopo il submit (tamite GET ovviamente). Punterò su questo adottando il redirect 301.

    Grazie per i consigli! Se qualcun'altro ha dei suggerimenti, sono bene accetti (specialmente per quanto riguarda il redirect).


  • User Newbie

    Ho buttato giù due righe.

    La pagina del form: index.php
    [php]<?php
    if (substr($SERVER["REQUEST_URI"], -5) == ".html"){
    $vet = explode("
    ",$SERVER["REQUEST_URI"]);
    echo "user: ".$vet[0]."<br> email:".$vet[1];
    }
    echo"<html>
    <form method="POST" action="parse.php">
    user: <input name="user" type="text" value="you">
    email: <input name="email" type="text" value="[email protected]"><br>
    <input type="submit" value="invia">
    </form>
    </html>";
    ?>
    [/php]La condizione di selezione IF controlla l'URI in entrata: se termina con un ".html" allora printa i valori delimitati dalla sentinella "
    ", altrimenti fa compilare all'utente il form il quale invia i dati tramite POST alla pagina parse.php.

    La pagina che elabora e crea la nuova url (si noti il redirect 301): parse.php
    [php]
    <?php
    Header( "HTTP/1.1 301 Moved Permanently" );
    Header( "Location: http*://www*.example.com/".$POST['user']."".$_POST['email'].".html");
    ?>
    [/php]Questo pezzo di codice (tra l'altro senza controlli) costruisce la nuova URL e fa il redirect su essa.

    L'utente non se ne accorge del redirect: al click del submit si ritroverà alla pagina http*://www*.example.com/[email protected] (che sarebbe un link simbolico [...] )

    Le due pagine nel complesso vanno ottimizzate in caso di variabili non valorizzate e di possibili N variabili arbitrarie in entrata, nonchè controlli sul carattere sentinella, sulla URI, ecc... Ma la mia domanda è: visto che questo form è usato di continuo ed è in homepage, Google potrebbe bannarmi per l'uso di quel redirect (tra l'altro permanente) ?

    Grazie!


  • Super User

    Prego!
    😉

    Prima di risponderti, ma vuoi far comparire nella URL l'indirizzo e-mail dell'utente?
    😮

    Il consiglio che ti ho dato riguarda solo l'interrogazione di dati pubblici tramite modulo di ricerca, questo pensavo volessi fare.

    Insomma, a che serve quel modulo?


  • User Newbie

    @Webmaster70 said:

    Prima di risponderti, ma vuoi far comparire nella URL l'indirizzo e-mail dell'utente?

    No, no!!.. 🙂 non sono così tanto:fumato: 😮 Quello era solo un esempio.
    Il mio sito è d e c a l f o n t . c o m. Capirai a cosa serve quel modulo non appena visiti il sito ;). Prova a valorizzare tutti i campi e poi a battere Invio (non perdere il focus degli elementi, altrimenti javascript aggiorna la pagina solo con gli elementi valorizzati da dall'utente *).

    Il fatto è che google viaggia senza javascript e "batte" Invio inoltrando anche gli elementi non valorizzati (p.es: color=0 , pieces=1 ... e lungo andare ). Se fai una SERP su google del tipo site:www mio sito .com vedrai molte pagine duplicate, soprattutto verso la fine.

    Il consiglio che ti ho dato riguarda solo l'interrogazione di dati pubblici tramite modulo di ricerca, questo pensavo volessi fare.Esatto questo è ok. Ma io volevo implementare il sistema che ho descritto poco fa in modo da riscrivere la query-string in modo più elegante, tutto a favore di Google.

    • oppure entra con js disabilitato.

  • Super User

    Adesso ho capito, per fare si può fare, dubito sulla sua utilità,
    comunque mi spaventa il numero di pagine duplicate che un solo link interno ti può creare, pensa a tutte le possibili combinazioni font, dimensioni ecc. che ci sono. Tralaltro adesso sono tutte variabili passate in query string alla home page, non hanno nemmeno un pagina dedicata.

    Spostarle in una directory ed escluderle con robots.txt?

    Sono dubbioso, magari qualche esperto qui ti potrà dire, su quanto detto prima mi sentivo sicuro, su questo lascierei la parola.


  • User Newbie

    Non saprei... io attuerei quella soluzione del url rewriting, almeno per togliere di mezzo i valori di default che saltano fuori col Submit.
    Il fatto è che il crawler navigando "sceglie" e cambia i colori ogni volta, come abbiamo detto... quindi questa soluzione sarebbe vana.

    Forse la soluzione più opportuna è questa: implementare il form in ajax. Tolto il dente tolto il dolore.

    Quindi: la parte di refresh in ajax potrebbe coinvolgere questi eventi:

    • il cambio del testo, del colore, della dimensione, speculare, e la quantità
    • la scelta del font tra le categorie

    Mentre le categorie rimarrebbero così come sono (senza ajax).

    Sembra arduo!