When promoting a young site with which TIC to select sites for the purchase of links?

Question

Search Engine Optimization

It is necessary to promote a 1-year-old site with TIC 10 in organic search results (mainly Yandex) for medium-frequency queries (about 300 items). It is planned to promote with high-quality links - in articles, blogs. Sites with what size TIC should be selected for placement?

Answer 1

Promotion is not buying links. But blog posts are the right strategy. Just keep an eye on the quality of the text, and not so much as anything but the main link.
Ideally, links only from thematic sites.
If you buy, then take eternal links, do not sit on the needle of temporary links. Yes, it is cheaper, but the quality is not the same, and in the long run it will be more expensive. But of course it all depends on the goals, budget, topics.
The main thing in the promotion is not to rush. Especially with young sites, gradually filling everything in parallel.

Answer 2

Not only the TIC should be guided, you can catch up with it, but the site will still be G

Answer 3

You create a crud of the component and its types (carousel, contacts, and what fantasy is enough for), make a selection from the database. Be sure to add type_id to the component. For each component you create a widget, with the corresponding view. Then you can either display conditions, or a switch in index.php.
I do like this:

foreach ($components as $component) {
        switch ($component->type) {
            case Component::TYPE_CAROUSEL:
                echo Carousel::widget(['id' => $component->id]);
                break;
            case Component::TYPE_BLOCKS:
                echo Blocks::widget(['id' => $component->id]);
                break;
            case Component::TYPE_MAP:
                echo Map::widget(['id' => $component->id]);
                break;
            case Component::TYPE_CONTACT:
                echo Contact::widget(['id' => $component->id]);
                break;
        }
    }

And when creating a component, you can use scenarios() for different types of fields.

Answer 4

This season it is fashionable to create constructors like this !
Seriously, can you explain what the problem is - in terms of devops, in the sense of how to create a database / reload nginx, etc., or in terms of what will be on the site and how the user will manage it? If the first - you need to understand your scale, how many sites, how many servers, database size, load. If the second - then you need to start explicitly with the technical specifications and design, otherwise you can only blame everything on the encoder)))
UPD . Since it is the deployment process that is of interest, let me share my thoughts, since I have little experience.
In general, the algorithm is rather stupid - first do everything by hand, and then write a script that does the same =)
First, decide whether all your sites will work on the same codebase (most likely yes, if not, this is closer to shared hosting). Next, decide if everyone needs their own personal docroot - it depends on how you store / distribute static. If the statics add up somewhere far away (like on s3) - you can get by with one for everyone, but IMHO it's still easier when everyone has their own.
You get a structure like this:

app
public
    1
        static
        index.php
        config.php
    2
    ...

index.php connects the config and starts the application.
Next, you need to make public/1 open on a host like 1.hosting.com - this is nginx with regular expressions.

server {
    server_name   ~^(?<site_id>.+)\.hosting\.com$;
    root    /var/www/public/$site_id;
    ...
}

By the way, if you need a site ID, it's easy to throw it there:
There is a nuance with the launch of PHP. According to the mind, everyone should have their own user, their own fpm pool, etc. But graceful reload did not work for php-fpm at one time, after adding the pool and restarting, all clients received 502. I eventually spat and began to serve everyone with one pool, limiting myself to open_basedir, but if the user has at least a hypothetical opportunity to get to the code ( for example, some template editor) - you don’t need to do this =) pass open_basedir in the nginx config something like this:
To connect your own domain, use map, it's good in nginx =)

map $http_host $site_id {
    site.com    1;
    site2.com  2;
}

This design can be pulled out into a separate file and generated automatically.
With a database, everything is simple: if you can make everyone sit in one database, then do it =) If not, make a reference dump and a script that creates a new database from it. And then we puzzle over how to roll out migrations over a bunch of databases and machines =)
We do this with the control script: we screw up the scripts themselves (which is convenient, php will do just fine) and http api to them when the user does something on the "main" site , this api twitches, it will make life easier when you stop getting into one server.
To restart nginx and other dumb operations, I started separate sh-scripts and put them in sudoers for the user from which the api is running.
It is useful to put a queue between the "main" site and the api,
In principle, everything is simple, but this is of course amateur performance on the knee =) I did not find the manual "we write a website builder for dummies", and in general there are not so many of them alive, no one particularly shares their experience. I was most helped by studying the work of shared hosting, although there is not enough information about it.